SeatLayer MCP

The remote SeatLayer MCP lets Claude, ChatGPT, another MCP host, or your own agent build and publish seating charts and run events in SeatLayer: prices, single-seat prices, sales, close times, channels, orders and reports. SeatLayer supplies deterministic tools, validation, rendering, and review gates; the connected host supplies the model.

What it covers

Selling stays with the Server API and your checkout. An agent connected through this server can prepare and publish the map buyers use and run events, but it cannot sell a seat, and it can’t refund or charge anyone.

Server URL: https://mcp.seatlayer.io/mcp, over Streamable HTTP. The dashboard’s Agent connections page shows the URL for your environment. For chat hosts such as Claude and ChatGPT, use https://mcp.seatlayer.io/mcp?tools=build; see toolsets.

Choose a setup guide for Codex, Claude, or ChatGPT, and review the current capability matrix before enabling tools.

Claude Code

claude mcp add --transport http seatlayer https://mcp.seatlayer.io/mcp

Then run /mcp in Claude Code to sign in. The server’s ready-made prompts (see Pick a path) appear as slash commands, for example /mcp__seatlayer__block-seats-safely.

Security boundary

A SeatLayer admin approves each connection on a consent screen. One tap on Allow gives the workspace shown and every permission below; Customize narrows it to one chart or turns permissions off. What a connection can reach:

• One chart, or every chart in this workspace. A workspace connection can list, select, and create charts in that workspace only.
• Chart work: build and edit, validate and review, and request publication.
• Manage live events allows closing sections and blocking seats on events that are already selling.
• Read reports allows reading an event’s history, its prices, and its sales, money and door counts, never a buyer’s details.
• Manage sales channels allows reading an event’s channels and their sales, moving seats between them, changing a channel’s name, sale route and prices, pausing and archiving it, and making buyer links and partner report links. It stands for the dashboard’s channel permissions.
• Set prices and releases allows changing an event’s prices, ticket releases and when its sections go on sale, each confirmed by the person in chat first.
• Create and run events allows creating, editing and duplicating events, and opening, closing and reopening their sales, archiving and deleting them, each change to an event on sale confirmed by the person in chat first.
• Change seat categories allows moving seats to another category on an event that is already selling.
• Look after orders allows finding and reading an event’s orders, with the buyer’s name and contact details, and resending tickets. It can only ask for a refund or cancellation: an org admin approves each one in the dashboard before any money moves.

Every call that uses one of the event checkboxes beyond Manage live events (such as Read reports or Manage sales channels) checks again that the person who connected the agent is still a member with a role that may do it in the dashboard (admin or designer for reports, prices, event set-up and orders, admin for sales channels). If not, the call is refused and the agent asks the person to reconnect.

The token cannot reach other workspaces, members, billing, or API keys, and reaches buyers’ details only through Look after orders. Event tools see only events created from the charts in scope: on a workspace connection, the events of every chart in the workspace, with no chart selected first. Access tokens expire after an hour and refresh tokens rotate. Each connection can make up to 300 tool calls per minute.

Compatible hosts need:

• remote Streamable HTTP MCP;
• protected-resource discovery;
• OAuth 2.1 authorization code flow with PKCE S256;
• the resource parameter and rotating refresh tokens; and
• MCP image content for reference and preview inspection.

Never give the model a SeatLayer secret API key.

It asks you first

For an event on sale, the agent shows a plan and waits for your yes. A yes covers that plan only; if the seats change first, it plans again. A chart is published only after you approve its review. Your admins get one email about agent changes at most every 15 minutes per agent. History names the agent, and an agent’s chart publish can be undone in one click. Refunds need an admin: the agent can’t refund or charge anyone; it can ask, and an admin approves it in Orders.

Tools by area

The server offers only the tools the connection is allowed to use and the toolset in its URL asks for, so a read-only, chart-only or ?tools=build connection sees fewer. Call get_capabilities for the list your connection has.

find_events searches the connection’s events by name, start date or sales state, with sold, held, blocked and available seats, 20 at a time. get_seats shows what chosen seats are now (free, held, booked, blocked, reserved under a name, or off sale through the Event Configuration), chosen the same way plan_inventory_change chooses them, up to 200 a page. It names a private sales channel only for a connection that may read channels.

get_event_log and get_event_report need Read reports. The log lists each change newest first with who made it: a member, a buyer route, the system, or an agent connection by its name and the member who connected it. The report gives seats by status and category with their booked value, money taken by channel and payment method with refunds and discounts, bookings and sales per day or hour, and door counts (checked in against expected). Neither returns a buyer’s name, email, phone, order or door list.

An event is on sale once its sales leave setup (testable, live, paused or ended), or as soon as a buyer holds or has bought a seat. Every change to an event on sale goes through a plan the person agrees to in chat, however small. The four direct tools work only while an event is still in setup: on an event on sale they refuse with live_event_needs_plan and name the plan action and its inputs to use instead. They need Manage live events, and moving an event to the latest chart or binding a configuration also needs publishing.

To change an event on sale, the agent plans first. plan_inventory_change takes an action and, for most actions, a selection by seat labels, rows, sections or categories, up to 5,000 seats. It changes nothing and returns counts, a breakdown per section and a plain summary, plus a plan id valid for 15 minutes. The agent shows the summary, and only after the person says yes in chat calls apply_inventory_change with that plan id. Held and booked seats are always skipped, seats that changed since the plan are left alone and listed, the same plan id never applies twice, and only the connection that made a plan can apply it. Event history records the change with the connection and the reason.

Planning needs only read access, and the plan’s summary says which permissions applying needs. Channel plans are the exception: their summaries name partners, prices and links, so making one already needs Manage sales channels and an admin role. The channel reads need the same; get_channel_report shows money only with Read reports too. No channel tool ever returns an existing link: a lost buyer link is replaced with rotate_access_link. list_event_reservations lists an event’s named reservations and its other blocked seats, grouped by reason, with who made them; it needs Manage live events, and because it only reads, a read-only connection with that permission lists it. Publishing and approval tools need publish permission. Reference, blueprint, and capacity tools need the reference-chart feature, and Event Configurations need that module on your account.

Event prices and sales setup

get_event_pricing reads one event’s prices per category and ticket type (each the event’s own or the chart’s, and whether the chart has moved since), what is held or booked, its ticket releases and what each has sold, when its sections go on sale, the checkout hold time and how its tables sell. It needs Set prices and releases or Read reports.

Changes go through the same plan, yes in chat, then apply as seat changes. Each runs the dashboard’s own save, and each plan is tied to the event as the person saw it: if someone changes the prices, releases or settings in between, applying is refused and nothing changes, and the agent plans again. Holds and bookings always keep the price already promised; new selections use the new one. On a free event the summary says there is no price change for buyers.

Event set-up and sales

create_event makes a new event (show date) from a published chart, and duplicate_event copies one to a new date with its prices, releases, blocks and settings but no orders. Both make a draft in setup, nothing on sale, and a retry makes one event, not two. create_event with mode: "test" makes a test event: buyers pay with test payments and no real money moves. Give create_event a timezone; without one, the event takes the usual zone of the chart’s other events, then the workspace’s, then the organization’s. update_event changes a name, venue, doors or end time, description, buyer page language, ticket limits (maxTicketsPerOrder, maxTicketsPerBuyer) or external reference, and the start date or time zone while the event is in setup. get_event reads an event’s settings, sales state and seat counts, its checkout (who runs it, the payment provider and whether it can take the event’s payments, and the event page link once it is shared), and says in plain words what still stops it going on sale, and what going live will still need (sales.goLive). All four need Create and run events.

Sales and the rest of an event’s life go through the same plan, yes in chat, then apply. Each plan is tied to the event as the person saw it, and planning lists every check applying will meet, so a plan with a blocker has no plan id.

Orders

list_orders, find_order (by order reference, ticket code, name, email, phone or seat), get_order and get_order_timeline read an event’s orders, including the buyer’s name and contact details. resend_tickets emails an order’s tickets again to the address already on it, at most three times an hour per order. All need Look after orders and an admin or designer role.

request_order_refund refunds and cancels nothing. It checks the order as the dashboard’s Refund and Cancel buttons would, then returns a link that an org admin opens on the Orders page to approve or decline; the link expires after 24 hours and works once. Approving runs the refund or cancellation under the admin’s own sign-in. get_order_timeline shows the requests an agent made.

Toolsets

A host sends the name, description and inputs of every listed tool to the model on every turn. With every permission ticked, all 160 tools come to about 220 KB of definitions per turn. Most chat work (build a venue, change prices, add a bar, check and publish) needs far fewer, so the connection URL can pick a set:

Sets combine with commas, for example ?tools=build,trace,3d. trace and 3d always bring build with them; events does not, so use ?tools=build,events to edit the chart as well. Unknown names are ignored.

Sign-in works the same with the query on the URL. A toolset only changes which tools are listed; the grant approved on the consent screen still decides what a call may do.

readonly=1 is the one option that also refuses calls. Tools that change a chart or an event are not listed, and a call to one is refused whatever the grant allows. Choosing a chart with select_chart still works. get_capabilities reports readOnly: true. To make changes, reconnect without readonly=1. get_capabilities reports the sets. To add a set, reconnect with a different ?tools= value.

In discover mode the agent finds the tool a request needs with search_tools, reads its inputs with get_tool, and runs it with run_read_tool or run_write_tool. A run is checked exactly like a direct call: the grant, the Designer features, readonly=1 and the tool’s own limits. Jobs no tool can do come back marked as not possible, with where to do them instead, and report_missing_tool tells SeatLayer about the rest. Discover mode combines with readonly=1 (9 tools, without run_write_tool) and with a set, for example ?tools=discover,events.

Use ?tools=build in Claude and ChatGPT for everyday chart work. Use the plain URL in Codex, or add ,trace when the agent will trace a floor plan.

Pick a path

get_capabilities returns a step-by-step playbook for each common job, and the server offers the same jobs as ready-made prompts that hosts such as Claude show in their prompt picker:

Each prompt takes an optional request in your own words. A connection lists only the prompts it can carry out: ?tools=events lists the event prompts and none of the chart ones, and a readonly=1 connection lists client-report only. In a host without a prompt menu, ask in your own words; the agent follows the same steps.

Stages, landmarks such as bars, entrances and exits, text labels and named areas such as a dance floor are added with words: beside the layout, in its centre, or beside a named section, row or table. Gates and step-free routes have their own tools (see the table above). Not possible over MCP yet: drawing section outlines, or placing anything at an exact position. Agents are told to say so and send the user to the Designer for those steps.

Tracing a floor plan, end to end

Why it is not an image converter

A single vision response cannot guarantee:

• authoritative seat count or labels;
• correct accessibility and pricing;
• containment-safe geometry;
• readable buyer behavior at several zoom levels;
• exact revision review; or
• safe publication.

The MCP therefore separates evidence, semantic confirmation, deterministic geometry, machine validation, visual review, and publication.

Start with this prompt

Use the SeatLayer connector to build this seating chart with me.

Start with get_capabilities and follow the staged reference workflow.
Treat every uploaded image as evidence, not authoritative seat inventory.
Inspect the overview and all required detail tiles before interpreting a dense plan.
Record unresolved labels, counts, accessibility, and pricing as questions.
Use semantic tools and SeatLayer's deterministic compilers; do not invent coordinates.
After each bounded change, validate and render every floor.
Show me the buyer preview and reference alignment evidence.
Prepare the exact revision for review, but do not approve or publish without
my explicit decision.

Agent implementation rules

• Use the newest expectedUpdatedAt on mutations to avoid overwriting concurrent edits.
• Split large semantic region sets into bounded, disjoint calls and read back the merged canonical state.
• Do not let a supplemental source replace the configured geometry source.
• Do not create inventory from unconfirmed image counts or labels.
• Prefer semantic intents; public MCP tools intentionally exclude arbitrary geometry nudges and several Designer-only controls.
• Treat machine validation as necessary but insufficient for visual approval.
• Preserve published booking identities and safe-mode constraints.
• Wait out a plan that is still being read (see below); never treat it as a failure.

When a floor plan is still being read

SeatLayer reads an uploaded plan in the background, and a first read takes up to a minute. Until it finishes, the tools that need the read answer with this error:

{
  "ok": false,
  "error": {
    "code": "reference_analysis_pending",
    "state": "reading",
    "retryable": true,
    "retryAfterSeconds": 5,
    "recoverWith": ["get_reference_regions"]
  }
}

The tools that answer this way are get_reference_regions, get_reference_region, submit_region_semantics, list_unresolved_reference_questions, diff_vs_reference, restore_reference_sections, propose_reference_blueprint and prepare_chart_review.

• Wait retryAfterSeconds, then call the same tool again. Nothing was changed, so the retry is safe.
• reference_analysis_failed (with retryable: false) means the plan could not be read. Tell the person, and suggest uploading a clearer image or removing the plan. Don’t loop on it.
• HTTP callers get the same code in a 409 response, with a Retry-After header while the plan is being read.

Human review gate

Before approval, verify:

1. every floor and buyer scene is present;
2. source overlays/diffs match the intended geometry;
3. labels, capacity, accessibility, categories, and prices are authoritative;
4. no private reference appears in buyer output;
5. mobile and desktop interactions are readable;
6. the revision hash still matches the prepared packet; and
7. the reviewer understands the effect on new and existing events.

Definition of done

• OAuth scope is the intended chart or workspace, and only the boxes the job needs are ticked.
• Source classification and required tiles are complete.
• All inventory facts are confirmed.
• Deterministic validation passes on every floor.
• Buyer 2D/3D and mobile/desktop evidence is reviewed.
• Approval is attached to the exact unchanged revision.
• Publication is an explicit human-authorized action.
• The handoff records assumptions, open questions, and the published version.

Continue with reference plan import, sections and seat plans, or publishing and versioning.