Edinburgh Fringe 2026 for machines — MCP server and JSON API

MCP server — use the Fringe inside ChatGPT, Claude or Grok

Add it to ChatGPT, Claude, Grok or Cursor

Every client takes the same thing: the URL above. Pick yours.

claude mcp add --transport http ed-fringe-guide https://edfringeguide.com/mcp

{
  "mcpServers": {
    "ed-fringe-guide": {
      "type": "http",
      "url": "https://edfringeguide.com/mcp"
    }
  }
}

No account, no key, no OAuth — if a client asks for credentials, choose “no authentication”. Anything that speaks the Streamable HTTP transport will work; a client that only supports stdio needs a bridge such as mcp-remote.

Not currently possible in the consumer Gemini app or Qwen Chat, neither of which offers a custom-connector screen. Gemini CLI and Qwen Code both do, via the config file above.

What you can ask about the Fringe

Once connected, just ask normally — the assistant decides when to call the tools:

• “What’s on at the Fringe on the evening of 14 August, under £12, near Bristo Square?”
• “Find me free wheelchair-accessible comedy that’s still on sale.”
• “Build me a Saturday — four shows, nothing before noon, walking distance apart.”
• “Is there any way into [show] if it says sold out?”

Tools

Technical details

• Transport: Streamable HTTP, stateless. POST JSON-RPC to the endpoint; no session id needed.
• Tool results are plain text, written to be read by a model rather than parsed. Want JSON instead? That is what the REST API is for.
• All times returned are UK local. Prices are GBP.
• Rate-limited per IP, same as the rest of the site. Read-only: no tool writes anything.
• Machine-readable card: /.well-known/mcp/server-card.json

REST API — the same data as JSON

Read-only JSON over HTTPS. No key, no sign-up, CORS open to any origin. Every endpoint is a GET.

curl 'https://edfringeguide.com/api/v1/whats-on?date=2026-08-14&time_of_day=evening&max_price=12'

Endpoints

/api/v1 lists the endpoints, the valid values for every enumerated filter and the current limits. /api/v1/openapi.json is the OpenAPI 3.1 document, generated from the same constants the API validates against — so it cannot document one vocabulary and enforce another.

Filters

/shows and /whats-on take the same filters, combinable:

• query, venue, genre — text, partial match on the first two.
• date, time_of_day, start_after, start_before — UK local. Use start_after for “after 5pm”: it spans both the evening and late bands, which time_of_day cannot express in one call.
• max_price, free_only, two_for_one — money.
• available_only — at least one date still on sale centrally.
• rating, access_needs — repeat the parameter or comma-separate. Results carry an accessibility object naming which features each show has, split into permanent venue facilities and one-off access performances (captioned, signed, relaxed, audio described, touch tour). On a date query the access performances are those of THAT date.
• limit — 1–50, default 20. fields=description swaps snippets for full text.

Links

Every show carries show_url (this guide’s page) and booking_url (edfringe.com). Use them as given — the booking slug is not the show slug. A trailing -2026 is stripped for booking, and roughly a quarter of the catalogue carries one, so a URL built from slug is a plausible-looking 404:

show_url:    https://edfringeguide.com/show/sam-nicoresti-baby-doomer-2026.0
booking_url: https://www.edfringe.com/tickets/whats-on/sam-nicoresti-baby-doomer

The MCP tools carry the same pair as Page: and Book: lines on every result.

Accessibility

Eight tags, from the Fringe’s own vocabulary: WHEELCHAIR_ACCESS, WHEELCHAIR_ACCESSIBLE_TOILETS, AUDIO_ENHANCEMENT_SYSTEM, CAPTIONING, AUDIO_DESCRIPTION, SIGNED_PERFORMANCE, RELAXED_PERFORMANCE, TOUCH_TOUR_PERFORMANCE. Filter with access_needs (all listed must be met); read back which ones apply from accessibility.facilities and accessibility.access_performances.

max_steps (integer 0–99) filters on the stated number of steps into the performance space, which WHEELCHAIR_ACCESS cannot express — it is only yes/no. max_steps=0 is step-free. Only venues with a stated step count match: where the listing does not say, the show is excluded rather than assumed step-free, so a capped search is narrower than the programme rather than an exhaustive answer.

Show detail (/shows/{slug}) also carries access_guide when the show appears in the Fringe’s Enhanced Performance Guide: how audio description is delivered, the caption method, the interpreter and their position, touch-tour detail, and the relaxed-performance stimuli. It is published once per festival, so it describes how each provision works — which dates carry one stays each performance’s access tags, which are refreshed continuously.

Things it will not do quietly

An unrecognised parameter, an unknown rating or an unknown access tag is a 400, never a silently dropped filter. The difference matters: a dropped filter returns a plausible list you cannot tell apart from a real result, and for access_needs that would mean sending someone who needs step-free access the unfiltered programme.

{
  "error": {
    "code": "invalid_parameter",
    "message": "Unknown access need \"STEP_FREE\". Valid values: WHEELCHAIR_ACCESS, ..."
  }
}

Which availability field to read

Every performance carries five, and only one of them is the raw upstream value:

• on_sale — the one to trust. True when the date can be booked through the central box office: a bookable ticket status, not sold out, allocation remaining, and not cancelled.
• cancelled — the date is not happening. Reported separately from on_sale because a caller filtering on that alone cannot tell a cancelled date from a sold-out one. True on either signal the feed uses: its cancelled flag, or a CANCELLED ticket status — the two lag each other in both directions.
• allocation_exhausted — the central allocation is gone. False for a FREE_NON_TICKETED drop-in, whose percent_remaining of 0 means it never had an allocation rather than that it sold out.
• status_text — the same answer as a sentence, including the “contact the venue” case that a raw status enum reads as simply unavailable.
• sold_out — the raw Fringe feed field, not authoritative. In practice the feed leaves it unset, so "sold_out": false means “upstream said nothing”, not “tickets remain”. It is passed through unchanged rather than corrected, so that it keeps meaning exactly one thing. Do not branch on it.

percent_remaining of null means not yet measured, which is not the same as zero: such a date is still on_sale.

Where a show actually is

venue is the operator (“Monkey Barrel Comedy”); space is the room inside it (“Monkey Barrel 1”), which is the door an audience member has to walk into and the thing capacity measures. Big operators run several rooms, so the venue alone does not locate a show.

space is already resolved: it is null where the room name would only restate the venue (“The Vault” inside “Paradise in The Vault”), so you can render venue and space together without a redundancy check of your own.

Comparing availability between shows

A percentage is a share of each show's own allocation, so it is not comparable across rooms: 10% left is three tickets in a 30-seat room and seventy-five in a 750-seat house. Every show therefore carries capacity.

• capacity is the size of the room, from the Fringe spaces data. It is a per-show field, not a property of venue: two shows billed at the same venue are usually in different rooms, so a venue name tells you nothing about room size.
• null means the room size has not been researched (about 7% of shows). It never means small, and never means zero — skip those shows rather than defaulting them.
• percent_remaining × capacity is an upper bound on tickets left, not inventory. The central allocation is the room minus press seats, comps, holds and restricted-view kills, so the true figure is always lower. A show computing to “2 seats” may have none.

The API deliberately publishes the room size rather than a seat count: the count is an estimate, and an estimate in a machine payload gets quoted as stock.

Technical details

• All times are UTC with an explicit Z; the festival runs entirely in BST, so UK local is +1. Prices are GBP.
• dates_on_sale, available_only and the per-date on_sale flag all use one definition, so a filtered list can never contain a date the response then reports as not on sale.
• Responses are cached at the edge for 5 minutes (1 hour for venues). Errors are never cached.
• Rate limit: 300 requests per minute per IP, separate from the website's own budget.
• On a date query, everything under performance describes THAT date and everything under run describes the whole run. They are never merged into one field.
• Prefer plain files? /llms.txt and /llms-full.txt (the whole programme in one fetch), and every page on this site serves markdown to Accept: text/markdown.