The open gateway

What the gateway is, who runs it, how members plug in, the manifest an agent reads, how identity is handed along without personal data, and where a support ticket goes.

A gateway is one MCP endpoint in front of a dealership's tools. An agent connects once and reaches the store's inventory feed, offer providers, trade tool, payments desk, chat desk, CRM and anything else the dealer plugged in, each answered by the vendor that owns it.

The public demo runs at https://gateway.automotivemcp.ai/mcp. This demo runs on the open AutomotiveMCP gateway, hosted by PromptGraph.

Open, and optional

Open source. The gateway is Apache-2.0. Any website company, vendor, agent company or dealer group can host one and stay in control of it, and anyone can contribute to it. We would rather every host run the same open gateway than each company build a closed one. The public repository opens with the specification repository; until then, ask for access.
Optional. A gateway is a convenience, never a required middleman. Every member can still be called directly at its own endpoint.

Who is who

Party	Decides	In the demo
Operator	Hosts the gateway, keeps it up, answers support, routes tickets	PromptGraph
Dealer	Which tools connect for its store, and what each may do	Castle Kia of McHenry
Member	Answers its own tools, verifies every token itself	Eight simulated vendors, plus the in-house service scheduler a dealer can connect
Agent	Calls tools for the shopper	ChatGPT, Claude, Cursor, any MCP client
Shopper	Whether a vendor may contact them, and when to revoke	A fictional persona on the consent page

One gateway serves many dealers. core.list_dealers lists them, dealer tools take an optional location_id (section 11.4), and each dealer chooses its own members. Scoping is an authorization boundary: every per-hop token names exactly one location and each member refuses any other.

Members

A member is a vendor's tool behind the gateway. It has its own canonical URI, which is also the audience of every token the gateway sends it, and a manifest that says what it answers and what it needs. The demo's members are role names (Website inventory feed, Specials provider, OEM offers provider, Trade appraisal, Payments desk, Chat and BDC desk, CRM, Store knowledge), not real vendor brands.

The dealer connects members itself. In the sandbox dealer view a dealer picks a member from the catalog or pastes its MCP endpoint, reads what it asks for, sees its member probe result, approves its scopes, and it is connected. Its tools appear on the gateway's next tools/list and it gets a lane on every session page. The operator is notified automatically; no ticket is needed, though the dealer can still open one. In the public sandbox the base members are locked, catalog connections revert after a few hours, and the gateway never calls an endpoint it does not host.

To build one, see Bring your own tool.

The manifest an agent reads

/.well-known/automotivemcp-gateway.json says who runs the gateway and how to reach every party:

Field	What it holds
`operator`	Name, role, support URL and email, hours, status page, security contact
`dealers[]`	Each store: location_id, address, phone, the members it connected, its alias endpoint, its dealer view
`members[]`	Each member: member_id, role, manifest_uri, tools, `active` or `available`, which dealers use it, support contact
`routes`	Which members answer each tool, whether it fans out, whether a dealer connected it
`support`	How to file a ticket, the fields to include, and the escalation path
`sts`, `consent`	Token issuer and keys, the root delegation and per-hop token rules, receipts, status and disclosure URLs
`spec_sections`	Section 9 normative; sections 11 and 12 draft

Each member's own manifest is at /members/<id>/manifest.json; the schema is at /test-kit/schemas/member-manifest.json. The server card is at /.well-known/mcp.json, an A2A card at /.well-known/agent-card.json, and a plain map at /llms.txt.

Identity handoff

The shopper is one pseudonymous principal from the first call. No tool takes a name, phone or email, and the agent never holds one.

Root delegation. At a session's first call the gateway mints a root delegation it keeps: the shopper as a pairwise id, the agent as the actor (self-asserted), the most any hop may get, the dealers, 30 minutes.
One token per hop. Every member call gets its own ES256 token exchanged from the root (RFC 8693): one member, one tool, one scope, one location, a different pairwise id per vendor, never outliving the root. Members verify it themselves and return a section 12.8 audit record.
Step-up. A lead, a test drive, a service appointment or a text follow-up needs the shopper at contact_verified. The tool answers insufficient_scope with a one-time consent link.
Consent receipts. On the consent page the shopper picks a persona, types a code shown on screen and ticks what to share. The gateway seals one receipt per vendor (section 9), addressed to that vendor alone.
Contact by reference. The vendor verifies its receipt (signature, audience, disclosure hash, status) and asks the gateway for exactly the fields it covers. A vendor presenting another vendor's receipt is refused.
Revoke. From the session page the shopper revokes: every token stops, every receipt reads revoked, and the agent's next call fails with "access revoked by the shopper".

Section 9 is normative. Sections 11 and 12 are draft proposals: the demo runs them in one trust domain to find the gaps, and does not claim conformance.

Support routing

Step	Who	When
1	The member vendor	A member returns wrong data or errors
2	The gateway operator	Routing, sessions, limits, availability, or no answer from a vendor
3	The dealer	The store, its vehicles, or connecting a new member
4	AutomotiveMCP security	A security or privacy flaw

An agent can file the ticket itself: testkit.create_support_ticket fills in the gateway, operator, dealer, member, tool, session, trace link, recent errors and client, and routes it per the manifest. In the demo the ticket is recorded on the session page, NOT SENT. Every session page shows who runs the gateway and where tickets go.

Run your own

The gateway is a standalone Node 22 package with one dependency, the official MCP server SDK. It runs its members on loopback, keeps sessions in SQLite outside the checkout, and refuses any outbound connection beyond loopback.

cd packages/testkit-gateway
npm ci
GATEWAY_PORT=3310 node server.mjs          # or: node bin/amcp-testkit.mjs up
curl http://127.0.0.1:3310/health

Dealers, members and the operator are config (config/gateway.json). Put a reverse proxy in front of /mcp with buffering off, and keep /internal/ off the public host.