seatgeek

Endpoint

Hosted endpoint · transport http

Connect

This is a remote MCP server — point an MCP client at the endpoint URL. Clients with native remote support (Claude, Cursor, VS Code, …):

For stdio-only clients (older Claude Desktop, etc.), bridge with mcp-remote:

If the server requires authentication, add the provider's token/header (e.g. an X-API-Key) per its docs. A quick reachability check:

Tool quality observed · not scored

Heaviest: search 2800

From an anonymous initialize + tools/list capture measured 2026-10-20; tokens are chars/3.6 of each tool definition. Recorded for the Kin Score's agent readiness as an observed signal — it contributes no points yet.

Tools

• geocode_location — Convert a place name into geographic coordinates (lat,lon) and a canonical display name. Use this before calling eventSearch when the user names a place (e.g. "Brooklyn", "Austin", "Toronto"). Pass a bare city or place name; "City, State" strings are less reliable than the name alone. It does simple city-name matching and can't disambiguate a borough/neighborhood/metro — if a name resolves to an unexpected or far-off city (e.g. "Manhattan" → Manhattan, KS), retry with the parent CITY the user means (e.g. "New York"); re-sending the same name returns the same result.
• my_tickets — Look up the signed-in user's tickets across past and upcoming events. Two modes: 1. Browse — leave `event_ids` empty. Use `filter` (upcoming/past/all) and optional `query` for free-text search across event title, performer, and venue. Returns a summary list. 2. Lookup — pass `event_ids=[N, …]`. Returns full per-event detail for each event the user has tickets to, plus an `unmatched_event_ids` list for the requested ids the user does NOT have tickets for. Pass a single id to drill into one event; pass several to intersect against owned tickets (e.g. when joining a recommendations list). Full detail includes ticket groups with seat description, status, transferable/sellable flags, seat perks (text labels), order pricing (per-ticket + total), active listings, and outgoing transfers.
• search — Search SeatGeek events, optionally with their ticket listings. This is the first step for any query that names a team / artist / venue / city / date / category. Pick `detail` — this is the one decision that matters: - `detail='events'` (default): event summaries only. Use to find, identify, or list events ('when do the Mets play', 'comedy shows in NYC', 'is X on tour'). - `detail='events_with_listings'`: events PLUS their ticket inventory/pricing. Use whenever the user asks about price, availability, cheapest, best seats, a budget, or specific sections/seats. One call answers the whole question — do NOT call twice. The result summarises the FULL matched set: every distinct section (with counts), the seat features present, a per-event breakdown, and the overall price range — so you can read the exact section names / seat-feature ids off the output and refine without a second discovery call. Anchors (pass at least one; combine freely): `event_ids` when you already know the exact event(s) (e.g. from a prior `detail='events'` search) — pass one or several to lock EVERY mode to just those events and drill into their listings, sections, and pricing; it overrides the performer/venue/date filters (they're ignored when `event_ids` is set); `performer_ids` when the id(s) are already known (from pre-fetched context or a prior result) — pass SEVERAL for a matchup ('Mets vs Dodgers' → both ids), never concatenate names into one `performer_query`. For a matchup ALSO set `performer_match='all'` to return only the head-to-head games (`performer_match` defaults to 'any', which matches events with EITHER performer, i.e. every game of either team). `performer_query` ('Mets') for a single free-text name; or `venue_query` ('Citi Field'); `taxonomy` (pick the most specific value — 'mlb' < 'baseball' < 'sports' — allowed values are in the `taxonomy` schema); `taxonomy_ids` (list of category ids) when a category id is already known (e.g. from pre-fetched context) — it covers the FULL taxonomy space, unlike the curated `taxonomy` slug list; pass it to filter by a resolved category, and never retype a category word into `performer_query`; `main_event_ids` (parent event id(s)) to fetch an event's PARKING and add-on passes — pair it with `detail='events_with_listings'` to surface the parking listings for that event; `genre_slugs` for concert genres; to anchor by place pass `location_query` (a bare city or place name, e.g. 'Brooklyn', 'Austin') — it is geocoded for you, so do NOT call geocode_location first. Pass `location_coordinates` ('lat,lon' string, or a [lat, lon] pair) instead only when you already have coordinates (the user's own 'near me' location, or a prior geocode); if both are passed, coordinates win. Either pairs with optional `radius_miles`. The result echoes the place a `location_query` resolved to — if it's the wrong city, retry with the parent city name. Refinements (any `detail`): `performer_role` ('any' default — home AND away games / every appearance; narrow to `'home_team'` ONLY when the user says home ('Mets home games', 'when are they at home'), `'away_team'` when they say away/road. A team question with no home/away wording keeps the default: a fan asking about 'the Commanders-Titans game' means the game, whichever stadium it is at), `datetime_local_start`/`datetime_local_end` (ISO 8601 local), `day_of_week` (1=Mon…7=Sun; [6,7]=weekend), `day_night`, `season_stages`, `include_past_events`. Apply ONLY the filters the user actually stated — e.g. 'day games' sets `day_night='day'` alone; add `day_of_week` only when they name days or say 'weekend'/'weekday'. Don't narrow by something they didn't ask for. Listings-only refinements (apply when `detail='events_with_listings'`): `sections`, `seat_feature_ids`, `min_price_cents`/`max_price_cents`, `min_deal_quality`, `min_quantity`, `delivery_methods`, `accessible_only`, `exclude_obstructed`, `exclude_partial_view`, `general_admission`. `sections` and `seat_feature_ids` match EXACT values — never invent them. To target a tier the user names loosely (e.g. 'club', 'field level', 'bleachers'), do a first `detail='events_with_listings'` call WITHOUT `sections`, read the real section names + seat-feature ids from the result's summary, then call again with those exact values. Sort: events default `popularity`; listings default `deal_quality` descending — a higher deal quality means better value, so the best-value listings come first. Use `datetime` for schedules, `price`/`lowest_price` for cheapest-first. Paging: results are stably ordered and the header reports the full match count plus a per-event breakdown and overall price range (computed across ALL matches, not just the shown page). Rows show `per_page` at a time (listings default 30, events 15; max 50); when the header says more are available, request the next page with `page=2`, `page=3`, … keeping the same filters. (`per_page` applies to both modes; the legacy `limit` still works for listings but is deprecated.)

About MCP

The Model Context Protocol (MCP) is an open protocol Anthropic introduced for connecting LLM-based agents to external tools and data sources. Providers publish MCP servers that expose their API surface as structured, discoverable tools — an MCP-compatible client (Claude Desktop, Cursor, Cline, Continue, etc.) can connect to the server and call its tools without any per-provider integration code.

Browse every MCP server on the APIs.io network or compare with the broader Agent Skill surfaces of the same providers.

Work with this as data

Every MCP server here is available over the APIs.io API and to AI agents over MCP.

curl "https://apis.io/api/v1/mcp/seatgeek"

curl "https://apis.io/api/v1/mcp?limit=25"