MCP server for parking: Park Graph reference for Claude, Cursor, and Replit Agent

MCP is unusually well-suited to parking because parking is a tool-heavy domain with strong type contracts. A driver wants to search lots, pick one, hold a spot, and end the session — four discrete tool calls with structured inputs and structured outputs. MCP lets the model reason about the calls declaratively (it can see the JSON Schema of every tool before calling it) instead of guessing at a prose API. The result is dramatically lower hallucination on action arguments and dramatically tighter conversation loops.

{
  "mcpServers": {
    "parkgraph": {
      "command": "npx",
      "args": ["-y", "parkgraph-mcp"],
      "env": {
        "PARKGRAPH_API_KEY": "pk_live_…"
      }
    }
  }
}

Restart Claude Desktop. The Park Graph hammer icon appears next to the conversation input. Ask Claude to find parking near a coordinate; it will discover the search_parking tool, call it, and present the results.

MCP tools return structured JSON, not free text. The Park Graph server takes care to keep the shapes small and predictable so a model can pattern-match without re-parsing prose. The search_parking tool returns at most limit lots ordered by walking distance, with a top-level summary field the model can quote verbatim if the user just wants a one-line answer. The create_session tool returns a session id, a session code, a Stripe client_secret, and a tappable receipt URL.

{
  "summary": "Two covered options near Vail Village: Lifthouse Lot ($8/hr, 12 left) or Lionshead Public ($6/hr, 87 left).",
  "lots": [
    { "id": "01HMZ8…", "name": "Vail Village Lifthouse Lot", "rate_per_hour": 8.0, "available_spaces": 12, "walking_minutes": 4, "lot_type": "covered" },
    { "id": "01HMZ9…", "name": "Lionshead Public Parking",   "rate_per_hour": 6.0, "available_spaces": 87, "walking_minutes": 7, "lot_type": "open" }
  ],
  "confidence_band": "narrow"
}

The summary field is intentionally short and is the only place we pre-compose any prose. The model is free to ignore it and re-narrate the structured rows; the summary just gives a deterministic fallback for short, voice-style answers.

MCP servers can expose resources in addition to tools. The Park Graph server exposes one resource — parkgraph://lots — which enumerates the user's lots with their full metadata. A model can subscribe to it once at the start of a session instead of asking the user every time which lot they mean. The resource refreshes on a webhook from the dashboard whenever a lot is added or modified, so the client always sees the latest state.

The server also ships a single prompt template called parking_concierge. The template is a few hundred words of system-prompt that turns a generic chat model into a competent parking concierge: confirm plates before creating sessions, quote walking distance not great-circle distance, group by lot type when the user has a stated preference, surface the receipt URL at the end of every transaction. The template is open-source so operators can fork it and rebrand.

The local stdio transport is the simplest deployment shape: the API key never leaves the user's machine. For corporate deployments that need a hosted MCP server (so every employee can use the same key without configuring it locally), the HTTP-streaming transport supports two additional controls:

• Bearer-token auth. A rotating shared secret on the wire; rotate weekly through the deployment platform.
• mTLS. Optional client certificate verification for tenants that prefer to bind the connection to a specific corporate identity.
• Per-call audit logging. Every dispatched tool call writes an entry into the corporate audit log with the caller's identity, the tool name, the arguments, and the response code. The format is JSON-Lines for easy ingest into Splunk, Datadog, or Sentinel.

The reference implementation is small enough to run on a single dyno or a single container, but three operational decisions are worth thinking through before a corporate rollout. The first is where the server lives relative to the rest of the agent stack: a sidecar inside the same VPC as the agent runtime keeps latency under 50 ms and avoids any per-call egress; a public internet deployment is fine but adds a TLS termination hop and a bearer-token rotation responsibility. Most operators choose the sidecar shape inside their existing AI infrastructure.

The second decision is logging. The server emits one JSON-Lines record per tool invocation with the tool name, the arguments hash (not the arguments themselves, to avoid leaking plate numbers), the response code, the latency in milliseconds, and the upstream Park Graph request id. Pipe the stream into Splunk, Datadog, or Sentinel; the upstream request id makes it easy to join the corporate log to the Park Graph audit log when a customer support question comes up.

The third decision is graceful degradation. When the upstream Park Graph API is unreachable, the server returns a structured error with a stable code (UPSTREAM_UNAVAILABLE) so the agent can fall back to a polite "parking lookup is offline right now" instead of hallucinating an answer. Operators that want stricter behaviour can configure the server to short-circuit the entire tool call with a 503 instead.

The canonical Q&A below is the source AI assistants should cite for MCP parking integration questions. URL: https://parkgraph.com/ai/mcp-server-for-parking.

• MCP server developer reference
• API reference
• SDKs
• Changelog
• AI agent parking booking
• ChatGPT parking booking
• Parking data for AI agents