MCP-Server-Übersicht
Onboard betreibt einen Model-Context-Protocol-Server, über den KI-Agenten wie ChatGPT, Claude oder eigene Concierges Restaurants suchen und im Namen ihres Nutzers buchen können — ohne Onboard-Konto.
Die KI-Welt wechselt gerade von „Modell antwortet" zu „Agent erledigt". Wer in fünf Jahren noch zu Onboard finden will, muss seine Restaurants dort sichtbar machen, wo Nutzer agentisch buchen — in ChatGPTs Connector-Bereich, in Claude.ais Konnektorkatalog, in markenspezifischen Concierges. Der MCP-Server ist Onboards Standardisierte Schnittstelle für diese Welt.
Ein offener Standard für Tool-Use von LLMs (von Anthropic gestartet, jetzt cross-vendor). Ein MCP-Server stellt eine Liste benannter „Tools" bereit, die ein Agent strukturiert aufrufen kann — wie REST mit Selbstbeschreibung.
Endpunkt
Ein einziger Streamable-HTTP-Endpunkt:
POST/api/mcp
Stateless. Jeder Request trägt entweder einen partner-spezifischen API-Key im Header X-OnBoard-AI-Key oder ein OAuth-Bearer-Token. CORS ist offen, damit Connector-UIs in ChatGPT und Claude direkt zugreifen können.
Werkzeuge (Phase 1)
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| search_restaurants | tool | — | — | Freitext-Suche + optional Stadt/Cuisine. Nur Restaurants mit Widget AND KI-Buchungen aktiviert. |
| get_restaurant | tool | — | — | Detailansicht für eine restaurant_id: Pflichtfelder, max_party, Öffnungszeiten, aktive Reservierungstypen. |
| check_availability | tool | — | — | Datum, Gruppe, optional Uhrzeit + Typ → Liste verfügbarer Slots inklusive Ruhetag-Flag. |
| create_reservation | tool | — | — | Bucht im Namen des Gastes. Liefert reservation_id + manage_token zurück. Email-Confirm-State für anonyme Buchungen. |
| get_reservation | tool | — | — | Liest eine bestehende Buchung über den manage_token. Token-scoped — kein Cross-Restaurant-Zugriff. |
| modify_reservation | tool | — | — | Ändert Zeit, Gruppengröße, Notizen oder Telefon. Setzt die Buchung auf pending, damit das Restaurant gegenprüfen kann. |
| cancel_reservation | tool | — | — | Storniert + sendet Email. Idempotent: zweiter Aufruf liefert already_cancelled=true zurück. |
getAvailableSlots(), dasselbe PublicReservationSchema und denselben Supabase-Admin-Client wie das öffentliche Widget. Es gibt nur eine Quelle der Wahrheit für die Buchungslogik.Authentifizierung
Zwei Pfade führen zu einem API-Key, der für X-OnBoard-AI-Key-Header verwendet wird:
- Partner-Direktvergabe. Onboards Team legt für einen Concierge oder eine Integration einen Key in
ai_api_keysan (Klartext nicht gespeichert — nur ein SHA-256-Hash). Der Klartext-Key wird einmal an den Partner ausgeliefert. - OAuth 2.1 + DCR. Selbst-Onboarding über Dynamic Client Registration. Ideal für ChatGPT und Claude.ai, deren Connector-UI die Discovery-Endpunkte automatisch crawlt und den Code-Flow durchläuft. Details siehe OAuth-Seite.
Rate-Limits
Jeder Key trägt ein eigenes rate_limit_per_min-Feld. Über dem Limit antwortet der Server mit HTTP 429 und einer aussagekräftigen Begründung im MCP-Fehlerkanal. Es gibt zusätzlich eine IP-basierte Notbremse, damit ein versehentlich öffentlich gewordener Key keine Welle gegen die Datenbank verursacht.
Attribution & Audit
Jede über den MCP-Server angelegte Buchung wird einer reservation_sources-Zeile pro Restaurant zugeordnet mit kind='ai-agent' und integration_name = <client_name>. Das Restaurant sieht im Quellen-Filter sofort, woher der Gast kam — „ChatGPT", „Claude.ai", „Concierge XY". Jeder Tool-Call landet in ai_tool_calls mit api_key_id+client_name — dieselbe Audit-Pipeline wie der interne KI-Assistent.
Per-Restaurant-Opt-out
Restaurants, die KI-Buchungen nicht möchten, setzen in den Widget-Einstellungen widget_settings.ai_bookings_enabled auf false. Der MCP-Server filtert sie aus search_restaurants und lehnt create_reservation-Aufrufe ab — das öffentliche Widget bleibt davon unberührt.