MCP für Website-Chatbots: Tools mit OAuth und Freigaben anbinden

MCP macht Website-Chatbots handlungsfähiger - aber nur mit klaren Grenzen

MCP für KI-Chatbots ist kein Zauberstecker, der einem Website-Chatbot plötzlich beliebige Systeme anvertraut. Das Model Context Protocol beschreibt vielmehr eine gemeinsame Schnittstelle, über die ein Modell Tools entdecken und aufrufen kann: zum Beispiel eine Suche in einer Wissensbasis, eine Ticketabfrage, eine Terminlogik oder eine interne Prüfung gegen Produktdaten. Gerade für Website-Chatbots ist das attraktiv, weil viele Dialoge nicht bei einer Antwort enden. Besucher fragen nach Lieferstatus, Preisen, Kontaktwegen, Formularen, Verfügbarkeit oder nächsten Schritten. Ohne Tools muss der Bot erklären. Mit Tools kann er, kontrolliert und nachvollziehbar, relevante Daten holen oder vorbereitete Aktionen anstoßen.

Die entscheidende Frage lautet deshalb nicht: Kann ein Chatbot Tools nutzen? Die Frage lautet: Welche Tools darf er in welchem Kontext sehen, mit welchem Token aufrufen, mit welcher menschlichen Freigabe ausführen und mit welcher Protokollierung später erklären? Die endgültige MCP-Spezifikation vom 28. Juli 2026 verschärft genau diese Betriebsfragen. Sie macht den Kern zustandslos, verlangt relevante Metadaten pro Request und präzisiert, wie Remote-HTTP-Autorisierung, OAuth, Scopes und Token-Audience-Bindung zusammenhängen.

Was die Spezifikation 2026-07-28 für Website-Teams ändert

Die wichtigste Architekturveränderung ist der stateless core. Ein MCP-Server darf nicht davon ausgehen, dass frühere Requests auf derselben Verbindung bereits Kontext, Client-Fähigkeiten oder eine Session etabliert haben. Alles, was zur Verarbeitung nötig ist, muss im aktuellen Request stehen. Für verteilte Website-Infrastrukturen ist das praktisch: Requests können hinter Load Balancern, Edge-Gateways oder Worker-Plattformen auf verschiedene Instanzen fallen. Für Implementierungen heißt es aber auch: Keine versteckten Annahmen über Transport-Sessions, keine stillen Rechte aus einer vorigen Verbindung und keine Chat-Konversation als Sicherheitsgrenze.

Jede Anfrage braucht die erforderlichen _meta-Metadaten. Dazu gehören insbesondere die Protokollversion und die Client-Capabilities; Client-Informationen sind für Anzeige, Logging und Debugging hilfreich, aber nicht als Sicherheitsbeweis geeignet. Wenn eine Website mehrere Bot-Instanzen, Sprachen oder Kundenbereiche bedient, sollte diese Metadaten-Schicht bewusst validiert und geloggt werden. Sie ersetzt nicht die fachliche Autorisierung, sorgt aber dafür, dass der Server Requests korrekt einordnen kann.

Tool-Listen sind dynamisch, aber nicht beliebig

tools/list ist in der aktuellen Spezifikation paginiert und cachebar. Antworten können Cache-Hinweise wie ttlMs und cacheScope tragen. Gleichzeitig soll die Reihenfolge deterministisch bleiben, solange sich die zugrunde liegende Tool-Menge nicht ändert. Das ist mehr als Performance-Kosmetik: Wenn Tool-Kataloge stabil sortiert sind, können Clients sie verlässlicher cachen und Modell-Kontexte bleiben ruhiger.

Wichtig ist die Nuance bei der Autorisierung. Die Tool-Menge darf pro Request anhand der präsentierten Autorisierung variieren, etwa weil ein Token nur Leserechte auf Supportdaten, aber keine Schreibrechte auf ein CRM erlaubt. Sie darf jedoch nicht zufällig als Seiteneffekt vorheriger Requests auf derselben Verbindung schwanken. Für Website-Chatbots ergibt sich daraus ein klares Muster: Der sichtbare Tool-Katalog entsteht aus Rolle, Scope, Mandant, Sprache, Kontext und Risiko des aktuellen Requests.

Tool-Beschreibungen sind keine Vertrauensbasis

MCP-Tools beschreiben ihren Namen, ihre Eingaben, optional Ausgaben und Annotationen. Diese Metadaten helfen dem Modell und der Benutzeroberfläche, die Funktion zu verstehen. Sie sind aber kein Sicherheitsanker. Die Spezifikation sagt deutlich, dass Clients Tool-Annotationen als unvertrauenswürdig behandeln müssen, sofern sie nicht von vertrauenswürdigen Servern stammen. Ein Tool, das sich als schreibgeschützt beschreibt, muss serverseitig trotzdem so gebaut sein, dass es keine schreibenden Nebenwirkungen ausführt.

Das gilt auch für strukturierte Ergebnisse. Ein outputSchema hilft, Antworten zu validieren und nicht nur Freitext ans Modell zu geben. Trotzdem müssen Server Eingaben prüfen, Zugriff kontrollieren, Rate Limits setzen und Ausgaben bereinigen. Ein Website-Chatbot sollte Tool-Ergebnisse nicht ungefiltert in sichtbare Antworten übernehmen, besonders wenn externe APIs, Kundendaten oder HTML-nahe Inhalte beteiligt sind.

OAuth: Der MCP-Server ist eine geschützte Ressource

Bei Remote-HTTP-MCP ist die Rollenverteilung entscheidend. Ein geschützter MCP-Server agiert als OAuth-Resource-Server. Der MCP-Client handelt im Namen eines Resource Owners, also typischerweise eines Benutzers oder einer Organisation. Der Authorization Server interagiert mit dem Benutzer, falls nötig, und stellt Access Tokens aus. Der MCP-Server muss seine Protected Resource Metadata bereitstellen, damit Clients den passenden Authorization Server entdecken können. Der Authorization Server stellt mindestens eines der Discovery-Verfahren bereit, OAuth Authorization Server Metadata oder OpenID Connect Discovery; der MCP-Client muss beide unterstützen.

Für Produktteams heißt das: Der Chatbot sollte nicht selbst Passwörter, API-Keys oder fremde Tokens verwalten, wenn ein OAuth-Fluss vorgesehen ist. Er sollte den Benutzer zu einer klaren Freigabe führen, danach ein zweckgebundenes Access Token nutzen und die damit erlaubten Tools sichtbar begrenzen. Für Client-Registrierung sind Client ID Metadata Documents bevorzugt; Dynamic Client Registration bleibt nur rückwärtskompatibel erhalten und ist deprecated. Gerade bei Integrationen wie Kalender, CRM, Helpdesk, Dokumentenablage oder Shop-Systemen ist diese Trennung wichtig, weil dieselbe Unterhaltung oft zwischen öffentlichen Fragen und kontoabhängigen Aktionen wechselt.

Token müssen an die Zielressource gebunden sein

Die aktuelle Autorisierungsspezifikation verlangt Resource Indicators nach RFC 8707. Der Client muss in Autorisierungs- und Token-Requests den resource-Parameter setzen und damit die kanonische URI des MCP-Servers angeben, für den das Token gedacht ist. Der MCP-Server muss prüfen, dass das Access Token genau für seine Ressource ausgestellt wurde. Tokens dürfen nicht per Query-String übertragen werden, sondern gehören in den Authorization Header.

Diese Audience-Bindung verhindert eine gefährliche Abkürzung: Ein Token, das für Dienst A gedacht ist, darf nicht bei Dienst B akzeptiert oder weitergereicht werden. Website-Chatbots brauchen deshalb eine saubere Token-Grenze pro MCP-Server und pro Umgebung. Preview, Staging und Production sollten nicht dieselbe Audience verwenden, wenn sie unterschiedliche Ressourcen darstellen. Ebenso sollte ein Aggregator, der mehrere MCP-Server vor einem Modell zusammenführt, Tokens nicht vermischen.

Scopes sind ein UX- und Sicherheitsvertrag

Scopes sollten klein anfangen. Die Spezifikation empfiehlt, Scope-Hinweise aus WWW-Authenticate-Challenges zu nutzen und bei fehlenden Rechten einen Step-up-Flow zu erlauben. Praktisch bedeutet das: Ein Besucher kann zunächst mit lesenden Tools arbeiten. Erst wenn eine Aktion mehr Rechte braucht, etwa ein Ticket anzulegen, eine Datei zu schreiben oder eine Bestellung vorzubereiten, fragt das System gezielt nach der zusätzlichen Freigabe.

Ein gutes Consent-Design nennt nicht nur den Integrationsnamen, sondern auch die Wirkung: Welche Daten werden gelesen? Welche Aktion wird vorbereitet? Wird etwas extern gespeichert, versendet oder dauerhaft geändert? Für sensible Operationen sollte der Benutzer eine echte Bestätigung sehen und ablehnen können. Das ist keine individuelle Rechtsberatung, sondern eine technische Gestaltungsregel: Freigaben müssen für Menschen verständlich, für Server durchsetzbar und für Audits nachvollziehbar sein.

Eine belastbare Architektur für Website-Chatbots mit MCP

Eine robuste Architektur trennt Modell, Tool-Fassade und Zielsysteme. Der Website-Chatbot spricht nicht direkt mit jedem Drittanbieter, sondern mit einem MCP-Client oder Gateway, das Protokollversion, Client-Capabilities, Auth-Status, Rate Limits und Observability kontrolliert. Dahinter liegen MCP-Server für einzelne Integrationen oder fachliche Bereiche. Jeder Server deklariert nur die Tools, die für den aktuellen Request erlaubt sind, und validiert jeden Aufruf erneut.

Die Tool-Fassade sollte stabile Namen, enge Eingabeschemas und klare Ausgabeschemas verwenden. Tool-Namen müssen eindeutig genug sein, besonders wenn mehrere Server ähnliche Funktionen wie search, create oder lookup anbieten. Bei Aggregation hilft ein Namensraum oder Präfix. Parameter sollten so gestaltet sein, dass das Modell keine geheimen Rohdaten erfinden muss. Wenn ein Vorgang über mehrere Requests läuft, sollte der Server einen expliziten, kurzlebigen Handle zurückgeben und diesen bei jedem Folgeaufruf neu autorisieren.

Ein zweiter Baustein ist die Benutzeroberfläche. Besucher sollten sehen, wenn ein Tool aufgerufen wird, welche Eingaben gesendet werden und wann eine Freigabe nötig ist. Für reine Lesezugriffe reicht oft ein transparenter Status. Für schreibende, kostenpflichtige, externe oder personenbezogene Aktionen braucht es eine bewusstere Bestätigung. Die Spezifikation lässt Oberflächenmuster offen, fordert aber klar, dass Anwendungen menschliche Kontrolle über Tool-Aufrufe ermöglichen sollen.

Rollout-Checkliste für MCP für KI-Chatbots

1. Tool-Inventar erstellen: Welche Systeme sollen angebunden werden, welche Tools sind nur lesend, welche verändern Daten, und welche brauchen menschliche Bestätigung?
2. Scopes definieren: Rechte nach Aktionen schneiden, nicht nach internen Teams. Ein Tool für Statusabfragen braucht andere Scopes als ein Tool zum Erstellen, Ändern oder Versenden.
3. OAuth-Discovery prüfen: Protected Resource Metadata, Authorization Server Metadata, Client-Registrierung und Redirect-URIs pro Umgebung testen.
4. Audience-Bindung erzwingen: Tokens nur für die kanonische MCP-Server-URI akzeptieren, niemals für falsche Ressourcen weiterreichen und nie in URLs legen.
5. tools/list deterministisch machen: Stabile Sortierung, Pagination, Cache-Hinweise und Autorisierungsfilter gemeinsam testen.
6. Schemas eng halten: Eingaben validieren, strukturierte Ausgaben nutzen und automatisches Netzwerkladen externer $ref-Ziele standardmäßig deaktivieren; optional nur mit Allowlist, Timeout, Größenlimit und Logging.
7. Freigaben im UI bauen: Tool-Name, Zweck, Eingaben, Zielsystem, Scope-Upgrade und Ablehnen-Option sichtbar machen.
8. Observability verankern: Request-ID, Tool-Name, Scope, Entscheidung, Fehler, Latenz und Ergebnisart loggen, ohne sensible Inhalte unnötig zu speichern.
9. Fehlerpfade üben: 401, 403, abgelaufene Tokens, fehlende Scopes, unbekannte Handles, Timeouts und abgelehnte Freigaben als normale Produktzustände behandeln.
10. Klein starten: Erst ein bis zwei risikoarme Lese-Tools live nehmen, dann schrittweise Step-up, schreibende Aktionen und weitere Integrationen ergänzen.

Typische Fehler bei der Umsetzung

Der häufigste Fehler ist ein zu breiter erster Token. Wenn ein Website-Chatbot nach der ersten Anmeldung sofort umfassende Schreibrechte bekommt, wird jede Modellentscheidung riskanter. Besser ist ein minimaler Startscope mit gezieltem Step-up. Der zweite Fehler ist ein Tool-Katalog, der aus internen Systemnamen statt aus Benutzerabsichten besteht. Ein Modell arbeitet zuverlässiger mit klaren, eng beschriebenen Aktionen als mit generischen Allzweck-Endpunkten.

Der dritte Fehler ist fehlende Trennung zwischen Modellvertrauen und Serververtrauen. Das Modell darf eine Aktion vorschlagen, aber der Server entscheidet, ob die Eingaben gültig sind, ob das Token passt und ob eine Freigabe vorliegt. Der vierte Fehler ist fehlende Nachvollziehbarkeit. Wenn später unklar ist, welches Tool mit welchem Scope welche Daten gelesen oder geändert hat, lässt sich weder Support noch Sicherheit sauber betreiben.

Weiterführende Vertiefungen

Dieser Beitrag behandelt die MCP-Integrationsschicht: stateless core, tools/list und HTTP-OAuth. Die folgenden Artikel vertiefen generische Tool-Sicherheit und Betrieb: Für das Berechtigungsmodell passt KI-Chatbots: Tools sicher mit Rechten und Bestätigungen nutzen. Für konkrete Tool-Aufrufe lohnt sich KI-Chatbot-Tool-Aufrufe sicher gestalten. Wenn Tool-Ergebnisse maschinenlesbar bleiben sollen, passt Strukturierte KI-Chatbot-Ausgaben validieren. Für Betrieb und Fehlersuche ist KI-Chatbot-Observability für Traces, Retrieval und Tools die technische Fortsetzung.

Offizielle Quellen

Die fachliche Grundlage ist die finale MCP-Spezifikation 2026-07-28: die Seite zu MCP Tools, die MCP Authorization, der offizielle Beitrag The 2026-07-28 Specification und der Base Protocol Overview.

Fazit

MCP für KI-Chatbots wird dann wertvoll, wenn Website-Teams es nicht als offene Werkzeugkiste, sondern als kontrollierte Integrationsschicht verstehen. Die Spezifikation 2026-07-28 passt gut zu moderner Web-Infrastruktur: zustandslose Requests, cachebare Listen, routbare HTTP-Header und explizite Autorisierung pro Ressource. Gleichzeitig macht sie die Verantwortung deutlicher. Tool-Angebote müssen zum aktuellen Token passen, sensible Operationen brauchen menschliche Kontrolle, und jeder Aufruf muss serverseitig validiert werden.

Der pragmatische Start ist klein: ein lesendes Tool, ein enger Scope, ein klarer Consent-Text, deterministische Tool-Discovery und gute Logs. Danach lassen sich weitere Tools anschließen, ohne dass der Chatbot zur Blackbox wird. So entsteht aus einem Website-Chatbot kein unkontrollierter Agent, sondern ein nachvollziehbarer Assistent, der genau die Systeme nutzen darf, die für den aktuellen Benutzer und die aktuelle Aufgabe freigegeben sind.