MCP server

Give an AI assistant live access to EDMDb — artists, events, festivals and venues — over the Model Context Protocol.

This is the reference. If you are deciding whether to connect at all, the overview has example prompts and per-client setup without the protocol detail.

Authorization is now required

As of 10 August 2026 this endpoint needs a credential, and calls count against your monthly quota. Which tools you can call depends on your plan — see the table below. If you connected during the open beta, reconnect once and your client will handle the rest.

Endpoint

https://developer.edmdb.net/mcp

Connecting

Two ways in, and which one you want depends on whether a person is present to click “Authorize”.

OAuth — for assistants and connectors

The path for Claude, ChatGPT and anything else with a browser. Add a remote MCP server with just a name and a URL; the client discovers the rest and walks you through authorizing EDMDb. No secret is pasted anywhere.

Server configuration

{
  "name": "EDMDb",
  "url": "https://developer.edmdb.net/mcp"
}

Under the hood: an unauthorized request gets a 401 whose WWW-Authenticate header points at /.well-known/oauth-protected-resource/mcp, which names EDMDb as the authorization server. Your client registers itself, runs the authorization-code flow with PKCE, and receives an access token scoped to this endpoint. That is RFC 9728 discovery — none of it should need configuring.

Access tokens last an hour and your client refreshes them, so revoking access takes effect within the hour.

API key — for headless agents

For a script, a job or anything with no browser to complete a consent flow in. Use the same key as the REST API, as a bearer token:

Request

POST https://developer.edmdb.net/mcp
Authorization: Bearer edm_live_...
Content-Type: application/json
Mcp-Protocol-Version: 2026-07-28
Mcp-Method: tools/list

One header carries either credential — keys are recognised by their edm_live_ prefix, so nothing else changes. Create one on your developer dashboard.

Protocol

The server speaks MCP 2026-07-28, which is stateless: there is no initialize handshake and no Mcp-Session-Id. Each request carries its own context, names its method in an Mcp-Method header, and names the tool or prompt it is addressing in Mcp-Name. Capabilities come from server/discover rather than from a handshake response.

Clients on the 2025 revision still work. The endpoint serves them too, also statelessly — the handshake succeeds and simply issues no session to hold. Nothing needs changing on your side; when your client gains 2026 support you get the shorter path for free.

Discovery and the listing methods carry a one-hour cache hint: the tool surface only changes when we deploy, so a client is free to hold those results. Tool calls are never cacheable — event data is live.

Tools

Tool	What it does
`search_events`	Events by city, country or venue, with an optional date window. Upcoming-only unless you pass a start date.
`artist_info`	Profile for one artist — country, genres, aliases, real name, biography. Ask for a single field and you get a one-line answer.
`artist_upcoming_events`	Upcoming bookings for an artist, soonest first, with venue and city where known.
`venue_upcoming_events`	What is coming up at a venue, including the lineup where one is on record.

Tools are matched on names as a person would type them — a prefix, case-insensitively — not on internal ids, so “what is Tale of Us playing this summer” works without a lookup step. Where a prefix matches several artists or venues, the answer names the one it chose, so an ambiguous match is visible rather than silent.

What each plan can call

Your tools/list describes exactly what you can call: a tool your plan does not include is not advertised, rather than advertised and then refused. So an assistant never tries a tool it cannot use.

Tool	Free	Premium	Pro
`search_events`	Yes	Yes	Yes
`artist_info`	Yes	Yes	Yes
`artist_upcoming_events`	—	Yes	Yes
`venue_upcoming_events`	—	Yes	Yes

Free covers discovery — what is on, and who an artist is. The itinerary tools are the expensive ones and where a real integration lives, so they are on paid plans. Quotas are shared with the REST API and counted per account rather than per credential; rate limits and quotas has the numbers. Upgrading takes effect on the next call, with nothing to reconnect.

Reading the results

Every tool answers twice. content is prose for the model to read. structuredContent is the same answer machine-shaped, validated against the tool’s declared outputSchema, and it uses the same vocabulary as the REST API — snake_case, an explicit null for an absent value, ISO-8601 instants, ISO-3166 country codes.

start_at is an absolute UTC instant; timezone is the zone it should be read in.
A null timezone means the stored time of day is not trusted — use the date only. The prose does exactly that, omitting the clock rather than printing a time that could be hours out.
Every event carries a url to its page on edmdb.net. Attribution is a licensing condition on the free tier, so the link travels with the data.

Prompts

One prompt ships with the server: collectFestivalTripPreferences, which gathers destination, dates, genres and artists before planning a festival trip. It touches no data on its own — it exists so the assistant asks the right questions first, because a search with no destination and no date window returns noise. Its list arguments (genres, artists) are comma-separated strings.

MCP or REST?

MCP when a human is asking questions through an assistant and you want natural-language access without writing integration code.
REST when your own software needs the data — predictable shapes, pagination, and a contract that does not depend on a model's interpretation.

They read the same database, so neither is more current than the other.