MCP server overview
Onboard runs a Model Context Protocol server that lets AI agents — ChatGPT, Claude, custom concierges — search restaurants and book on behalf of their user, with no Onboard account required.
The AI ecosystem is shifting from "model replies" to "agent does". To stay reachable five years from now, restaurants need to be discoverable wherever users book agentically — inside ChatGPT's connector store, inside Claude.ai's connector catalog, inside brand-specific concierges. The MCP server is Onboard's standardized interface for that world.
An open standard for LLM tool use (started by Anthropic, now cross-vendor). An MCP server exposes a list of named "tools" that an agent can call in a structured way — REST with self-description, more or less.
Endpoint
A single Streamable-HTTP endpoint:
POST/api/mcp
Stateless. Every request carries either a partner-specific API key in the header X-OnBoard-AI-Key or an OAuth bearer token. CORS is open so connector UIs in ChatGPT and Claude can hit it directly.
Tool catalog (Phase 1)
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| search_restaurants | tool | — | — | Free-text search plus optional city/cuisine. Only restaurants with widget AND AI bookings enabled. |
| get_restaurant | tool | — | — | Details for a restaurant_id: required fields, max_party, opening hours, active reservation types. |
| check_availability | tool | — | — | Date, party size, optional time and type → list of available slots including a Ruhetag flag. |
| create_reservation | tool | — | — | Books on behalf of the guest. Returns reservation_id + manage_token. Email-confirm state for anonymous bookings. |
| get_reservation | tool | — | — | Reads an existing booking via its manage_token. Token-scoped — no cross-restaurant access. |
| modify_reservation | tool | — | — | Updates time, party size, notes or phone. Drops the booking to pending so the restaurant can re-check. |
| cancel_reservation | tool | — | — | Cancels + sends email. Idempotent: a second call returns already_cancelled=true. |
getAvailableSlots() and PublicReservationSchema that the public widget uses, against the same Supabase admin client. There is exactly one source of truth for booking logic.Authentication
Two paths produce an API key, both routed through the same X-OnBoard-AI-Key header:
- Direct partner provisioning. Onboard's team creates a key in
ai_api_keys(plaintext never stored — only a SHA-256 hash). The plaintext key is delivered to the partner once. - OAuth 2.1 + DCR. Self-service onboarding via Dynamic Client Registration. Designed for ChatGPT and Claude.ai, whose connector UIs automatically crawl the discovery endpoints and run the authorization-code flow. See the OAuth page for details.
Rate limits
Each key has its own rate_limit_per_min field. Above the limit the server returns HTTP 429 with a meaningful reason in the MCP error channel. There is also an IP-based safety net so an accidentally-leaked key cannot melt the database.
Attribution & audit
Every MCP-originated booking is attached to a reservation_sources row per restaurant with kind='ai-agent' and integration_name = <client_name>. The restaurant immediately sees the source in their filter — "ChatGPT", "Claude.ai", "Concierge XY". Every tool call also lands in ai_tool_calls with api_key_id and client_name — same audit pipeline as the internal AI assistant.
Per-restaurant opt-out
Restaurants that don't want AI bookings flip widget_settings.ai_bookings_enabled to false. The MCP server filters them out of search_restaurants and rejects create_reservation calls — the public widget keeps working unchanged.