Model Context Protocol (MCP): Fachsysteme kontrolliert an KI anbinden

MCP entstand bei Anthropic und wurde dort von David Soria Parra und Justin Spahr-Summers entwickelt. Bei der Veröffentlichung im November 2024 beschrieb Anthropic das Ziel so: Statt für jede Datenquelle eine eigene Anbindung zu bauen, sollen Entwickler gegen ein gemeinsames Protokoll programmieren. Mitgeliefert wurden Spezifikation, SDKs und Beispielserver für verbreitete Systeme. Vorbild war ausdrücklich das Language Server Protocol, das Programmiersprachen einheitlich in Entwicklungsumgebungen einbindet.

Im Dezember 2025 gab die Linux Foundation die Gründung der Agentic AI Foundation (AAIF) bekannt. MCP gehört neben goose von Block und AGENTS.md von OpenAI zu den Gründungsprojekten. Formal ist das Projekt heute als „Model Context Protocol a Series of LF Projects, LLC“ organisiert. Technisch entscheiden Lead Maintainer, Core Maintainer und Maintainer; Sitze sind an Personen gebunden, nicht an Unternehmen. Änderungen an der Spezifikation laufen über sogenannte Specification Enhancement Proposals (SEPs). Laut Linux Foundation unterstützen unter anderem Claude, ChatGPT, Gemini, Microsoft Copilot und VS Code das Protokoll – ein Server bleibt so auch bei einem späteren Wechsel des Assistenten nutzbar.

Die Spezifikation unterscheidet drei Rollen. Der Host ist die KI-Anwendung, mit der Menschen arbeiten, etwa ein Desktop-Assistent oder eine Entwicklungsumgebung. Darin laufen Clients, die jeweils eine Verbindung zu einem Server halten. Der Server ist das Bindeglied zum Fachsystem: Er beschreibt, was er anbietet, nimmt Anfragen entgegen und übersetzt sie in Aufrufe der jeweiligen Programmierschnittstelle.

Server bieten drei Arten von Funktionen an. Tools sind Funktionen, die das Modell ausführen lässt, etwa „Angebot als Entwurf anlegen“. Resources liefern Kontext und Daten, zum Beispiel ein Produktdatenblatt oder einen Datensatz. Prompts sind vorbereitete Vorlagen und Arbeitsabläufe, die Nutzer gezielt auswählen. Auf Clientseite sieht die aktuelle Spezifikation Elicitation vor: Ein Server kann darüber zusätzliche Angaben vom Nutzer anfordern, statt Annahmen zu treffen.

Die Revision vom Juli 2026 ist die größte Umstellung seit dem Start. MCP ist jetzt zustandslos: Der bisherige Initialisierungs-Handshake und protokollweite Sitzungen entfallen. Jede Anfrage trägt Protokollversion und Client-Fähigkeiten selbst mit. Server müssen über eine neue Methode server/discover mitteilen, welche Versionen und Fähigkeiten sie unterstützen. Benötigt ein Server Zustand über mehrere Aufrufe, vergibt er dafür ausdrücklich eigene Kennungen, die als normale Tool-Argumente übergeben werden.

Als Standardtransporte definiert die Spezifikation stdio für lokal gestartete Server und Streamable HTTP für entfernte Server, bei dem jede Nachricht als HTTP-POST an einen Endpunkt geht. Der ältere HTTP+SSE-Transport ist abgekündigt. Ebenfalls als veraltet markiert sind die Funktionen Roots, Sampling und Logging; neue Implementierungen sollen sie nicht mehr einbauen. Langlaufende Aufgaben sind in eine offizielle Erweiterung namens Tasks gewandert, die bei Bedarf zwischen Client und Server ausgehandelt wird.

Für HTTP-basierte Server beschreibt die Spezifikation eine Autorisierung auf Basis von OAuth 2.1. Der MCP-Server agiert als Ressourcenserver, der KI-Client als OAuth-Client, ein Autorisierungsserver – etwa Ihr bestehender Identity Provider – stellt die Zugriffstoken aus. Server müssen Protected Resource Metadata nach RFC 9728 veröffentlichen, damit Clients den zuständigen Autorisierungsserver finden. Für die Registrierung von Clients werden Client ID Metadata Documents empfohlen; die dynamische Client-Registrierung ist abgekündigt.

Wichtig für die Sicherheit: Token müssen ausdrücklich für den jeweiligen Server ausgestellt sein, und Server dürfen fremde Token weder annehmen noch weiterreichen. Die Spezifikation empfiehlt, zunächst nur minimale Scopes anzufordern und zusätzliche Rechte erst bei Bedarf über einen Step-up-Fluss zu holen. Lokale stdio-Server folgen diesem Ablauf nicht, sondern beziehen Zugangsdaten aus ihrer Umgebung – ein Grund, lokale Server nur aus vertrauenswürdigen Quellen zu installieren.

MCP verbindet ein Sprachmodell mit echten Systemen, und die Spezifikation sagt deutlich, dass Tools beliebige Codeausführung darstellen können. Sie verlangt, dass Hosts vor jedem Tool-Aufruf die ausdrückliche Zustimmung des Nutzers einholen und Daten nicht ohne Einwilligung an Server weitergeben. Durchsetzen kann das Protokoll diese Prinzipien nicht selbst; sie hängen an der Umsetzung in Host und Server.

Zwei Angriffsmuster sind besonders relevant. Bei Prompt Injection stehen manipulierte Anweisungen in Daten, die ein Tool zurückliefert, etwa in einer E-Mail oder einem Webtext, und lenken das Modell zu unerwünschten Aktionen. Beim sogenannten Tool Poisoning steckt die Manipulation in der Beschreibung eines Tools selbst. Die Spezifikation stellt deshalb klar, dass Tool-Beschreibungen und Annotationen als nicht vertrauenswürdig gelten, solange sie nicht von einem vertrauenswürdigen Server stammen.

Daraus folgt eine einfache Regel: Jeder Server ist eine Lieferantenbeziehung. Prüfen Sie Herkunft und Code, beschränken Sie die Rechte des technischen Kontos, trennen Sie lesende von schreibenden Tools und protokollieren Sie jeden Aufruf.

Der typische Einstieg ist ein lesender Server für ein System mit hoher Abfragefrequenz: Auftragsstatus aus dem ERP, Kontakthistorie aus dem CRM oder Dokumente aus dem DMS. Ein solcher Server bietet wenige, klar benannte Tools mit engem Eingabeschema an, etwa „Auftrag nach Nummer suchen“ statt einer frei formulierbaren Datenbankabfrage. Je präziser Name, Beschreibung und Parameter, desto zuverlässiger wählt das Modell das richtige Werkzeug.

Viele Softwarehersteller bieten inzwischen eigene MCP-Server an. Vor dem Einsatz sollten Sie klären, welche Tools enthalten sind, ob sich schreibende Funktionen abschalten lassen und wo der Server betrieben wird. Wo kein Herstellerserver existiert, ist ein eigener Server auf Basis der offiziellen SDKs meist ein überschaubares Entwicklungsprojekt, sofern das Fachsystem eine dokumentierte Programmierschnittstelle besitzt.