Was ein MCP-Server ist und was er nicht ist

Ein Sprachmodell an ein Unternehmenssystem anzubinden ist keine Aufgabe des Modells, sondern eine Aufgabe der Integration. Genau diese Schicht standardisiert das Model Context Protocol (MCP). Dieser Beitrag behandelt MCP als Protokoll und nicht als Produkt: was es festlegt, was es bewusst offenlässt und welchen Platz es in einer Unternehmensarchitektur einnimmt. Alle technischen Aussagen weiter unten stützen sich auf die offizielle Spezifikation. Revisionen der Spezifikation tragen eine Kennung im Format JJJJ-MM-TT und werden nur dann erhöht, wenn eine rückwärtsinkompatible Änderung eingeführt wird. Grundlage dieses Beitrags ist die Revision 2025-11-25. Die für den 28. Juli 2026 angekündigte Revision 2026-07-28 macht das Protokoll zustandslos, entfernt den initialize-Handshake und die Sitzungskennung, verschiebt Tasks aus dem Kern in eine eigene Erweiterung und erklärt Roots, Sampling und Logging mit einer zwölfmonatigen Frist bis zur Entfernung für deprecated. Die Angaben zu Sitzung und Primitiven weiter unten ändern sich mit dieser Revision.

Vor dem Protokoll: eine Brücke pro Paar

Vor MCP bedeutete das Anbinden einer KI-Anwendung an eine Datenquelle, für genau dieses Paar aus Anwendung und Quelle eigenen Code zu schreiben. Die ursprüngliche Ankündigung beschreibt es unverblümt: Jede neue Datenquelle verlangt ihre eigene Implementierung, was wirklich vernetzte Systeme schwer skalierbar macht. Die Branche kürzt das als N×M ab — N Anwendungen, M Systeme, dazwischen N×M von Hand geschriebene Brücken. Dieses Kürzel ist keine offizielle Terminologie, der beschriebene Zustand steht aber genau so im offiziellen Text. Der Tausch, den MCP vorschlägt, ist einfach: ein einziges Protokoll anstelle verstreuter Einzelintegrationen, sodass jede Seite das Protokoll genau einmal implementiert.

MCP wurde am 25. November 2024 von Anthropic angekündigt und als Open Source veröffentlicht; entwickelt haben es David Soria Parra und Justin Spahr-Summers. Die erste Veröffentlichung bestand aus drei Teilen: der Spezifikation samt SDKs, der Unterstützung lokaler MCP-Server in den Claude-Desktop-Anwendungen und einem quelloffenen Repository mit fertigen Servern für Systeme wie Google Drive, Slack, GitHub, Postgres und Puppeteer.

Am 9. Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation (AAIF), einen zweckgebundenen Fonds unter dem Dach der Linux Foundation. Mitgegründet wurde sie von Anthropic, Block und OpenAI, unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. MCP zählt neben goose und AGENTS.md zu den Gründungsprojekten. Die Maintainer-Struktur blieb unverändert: Der Vorstand kümmert sich um Budget, Mitgliedschaft und die Aufnahme neuer Projekte, während die einzelnen Projekte technisch vollständig autonom bleiben. MCP heute schlicht als das Protokoll von Anthropic zu bezeichnen, greift deshalb zu kurz. Genauer trifft es: von Anthropic initiiert und quelloffen gestellt, seit Dezember 2025 unter der AAIF innerhalb der Linux Foundation. Die offizielle Dokumentation nennt unter den Clients mit MCP-Unterstützung Claude, ChatGPT, Visual Studio Code, Cursor und MCPJam.

Architektur: Host, Client, Server

MCP folgt einer Client-Server-Architektur und definiert drei getrennte Rollen. Der MCP-Host ist die KI-Anwendung, die einen oder mehrere MCP-Clients koordiniert — etwa Claude Code oder VS Code. Ein MCP-Client ist die Komponente, die die Verbindung zu genau einem Server hält und im Auftrag des Hosts Kontext beschafft. Ein MCP-Server ist ein Programm, das MCP-Clients Kontext bereitstellt. Im Betrieb zählt dieses Detail: Der Host erzeugt pro Server ein eigenes Client-Objekt, und jeder Client hält eine dedizierte Verbindung zu seinem Server. Die Server sehen einander nicht.

Der Begriff MCP-Server sagt nichts darüber aus, wo der Code läuft; lokal oder entfernt ist beides möglich. In der Praxis bedienen lokale Server über stdio typischerweise einen einzigen Client, während entfernte Server über Streamable HTTP viele bedienen. Das Protokoll teilt sich in zwei Schichten: eine Datenschicht (Nachrichten auf Basis von JSON-RPC 2.0, Lebenszyklus, Primitive, Benachrichtigungen) und eine Transportschicht (Verbindungsaufbau, Message Framing, Autorisierung). MCP ist ein zustandsbehaftetes Protokoll. Eine Sitzung beginnt mit initialize, dort werden die Capabilities ausgehandelt, und Client und Server müssen sich auf genau eine Protokollversion einigen.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "example-host", "version": "1.0.0" }
  }
}

Die Spezifikation definiert zwei Standardtransporte: stdio und Streamable HTTP. Clients sollten stdio nach Möglichkeit unterstützen; eigene Transporte sind zulässig, solange sie das JSON-RPC-Nachrichtenformat und die Anforderungen an den Lebenszyklus einhalten. Streamable HTTP stellt einen einzigen MCP-Endpunktpfad bereit, der sowohl POST als auch GET unterstützt; der Server kann Antworten optional per SSE streamen. Der ältere HTTP+SSE-Transport aus Revision 2024-11-05 wurde durch Streamable HTTP abgelöst und ist deprecated. Über HTTP müssen Clients bei allen Anfragen nach initialize einen MCP-Protocol-Version-Header senden, und der gesendete Wert sollte die während initialize ausgehandelte Version sein; ein Server, der keinen Header erhält, geht von 2025-03-26 aus. Ein Server kann bei der Initialisierung eine MCP-Session-Id ausgeben und diese bei Folgeanfragen erwarten.

Die Spezifikation sagt ausdrücklich, dass MCP sich teilweise vom Language Server Protocol inspirieren lässt. Der Vergleich trägt: LSP hat die Nahtstelle zwischen Editor und Sprache standardisiert, MCP standardisiert die Nahtstelle zwischen KI-Anwendung und externem System.

Was ein Server tatsächlich bereitstellt

Server stellen ihre Fähigkeiten über drei Kernprimitive bereit. Unterschieden werden sie nicht danach, was sie tun, sondern danach, wer sie steuert:

• Tools — Funktionen, die das Modell aufrufen kann, um zu handeln: in eine Datenbank schreiben, eine externe API aufrufen, Dateien ändern. Gesteuert vom Modell. Methoden: tools/list, tools/call.
• Resources — passive, nur lesbare Datenquellen, die Kontext liefern: Dateiinhalte, Datenbankschemata, API-Antworten. Gesteuert von der Anwendung. Methoden: resources/list, resources/templates/list, resources/read, resources/subscribe.
• Prompts — wiederverwendbare, parametrisierte Interaktionsvorlagen. Gesteuert vom Benutzer; die Spezifikation geht davon aus, dass sie ausdrücklich aufgerufen werden. Methoden: prompts/list, prompts/get.

Tool-Eingaben werden mit JSON Schema deklariert. Damit stützt sich die Server-Seite auf das Schema statt auf das Modell: Ein eingehender Aufruf wird gegen das Schema validiert, bevor er die Geschäftslogik erreicht.

{
  "name": "get_order_status",
  "title": "Get order status",
  "description": "Returns the current status of a given order number.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderNumber": { "type": "string", "pattern": "^[A-Z]{2}-[0-9]{6}$" },
      "verbose": { "type": "boolean", "default": false }
    },
    "required": ["orderNumber"]
  }
}

Auf der Ressourcenseite trägt jede Ressource eine eindeutige URI und deklariert einen MIME-Typ. Über feste URIs hinaus können Server parametrisierte Resource Templates veröffentlichen — etwa eine Vorlage, die eine Stadt und ein Datum entgegennimmt. Der Fluss verläuft nicht nur in eine Richtung: Auch Clients stellen Servern Primitive bereit. Sampling erlaubt es einem Server, vom Modell des Hosts eine Completion anzufordern (sampling/createMessage). Elicitation erlaubt es einem Server, beim Benutzer zusätzliche Eingaben oder eine Bestätigung einzuholen (elicitation/create). Roots erlaubt es einem Server, die ihm zugestandene Dateisystemgrenze abzufragen. Logging rundet das Bild ab. Ein Tasks-Primitiv für lang laufende Vorgänge ist in der aktuellen Revision als experimentell markiert und sollte deshalb in einem Einführungsplan nicht als feste Annahme gelten. Server, deren Capabilities sich ändern, können Benachrichtigungen wie notifications/tools/list_changed senden — allerdings nur, wenn sie während initialize listChanged angekündigt haben.

Wo die Autorisierung tatsächlich stattfindet

An dieser Stelle entsteht beim Lesen die meiste Verwechslung. In MCP ist die Autorisierung auf Transportebene definiert und sie ist optional. HTTP-basierte Transporte sollten sich an die Autorisierungsspezifikation halten; STDIO-Transporte sollten ihr nicht folgen, sondern Anmeldedaten aus der Umgebung beziehen. Wer in einem lokalen stdio-Server nach einem OAuth-Flow sucht, schaut auf die falsche Schicht.

Über HTTP sind die Rollen eindeutig. Ein geschützter MCP-Server tritt als OAuth-2.1-Resource-Server auf. Ein MCP-Client tritt als OAuth-2.1-Client auf. Der Authorization Server ist eine eigene Partei — er kann beim Resource Server mitlaufen oder vollständig unabhängig betrieben werden. Diese Trennung begründet die Aussage, dass ein MCP-Server eine Autorisierungsgrenze ist: Der Server stellt keine Token aus, er prüft sie und begrenzt den Zugriff entsprechend. Der Abschnitt nennt als Standards, zu denen Konformität besteht, den OAuth-2.1-Entwurf, RFC 8414, RFC 7591, RFC 9728 und den Entwurf OAuth Client ID Metadata Documents. Davon getrennt verlangt dasselbe Dokument RFC 8707 für den resource-Parameter.

Die Anforderungen, die sich unmittelbar in Entscheidungen für den Betrieb übersetzen:

• MCP-Server müssen RFC 9728 (Protected Resource Metadata) implementieren, und Clients müssen es für die Ermittlung des Authorization Servers verwenden.
• Clients müssen PKCE implementieren und, soweit technisch möglich, die Challenge-Methode S256 verwenden; lässt sich die PKCE-Unterstützung nicht aus dem Feld code_challenge_methods_supported in den Metadaten des Authorization Servers bestätigen, muss der Client die Fortsetzung verweigern.
• Server müssen prüfen, dass Access Tokens ausdrücklich für sie als vorgesehene Audience ausgestellt wurden, und müssen Token zurückweisen, die sie nicht nennen.
• Beim Aufruf einer Upstream-API tritt der MCP-Server als eigenständiger OAuth-Client auf und darf das vom MCP-Client erhaltene Token nicht durchreichen. Token Passthrough ist ein ausdrücklich untersagtes Muster.
• Token dürfen nicht im URI-Query-String stehen; jede HTTP-Anfrage führt einen Authorization: Bearer-Header mit, auch innerhalb derselben logischen Sitzung.
• Sitzungskennungen sind kein Authentifizierungsmechanismus: Server dürfen Sitzungen nicht zur Authentifizierung verwenden.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="orders:read orders:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Write permission required"

Auch die Statuscodes sind festgelegt: 401, wenn eine Autorisierung nötig oder ein Token ungültig ist, 403 bei unzureichendem Scope, 400 bei einer formal ungültigen Anfrage. Bei 403 nennt der Server die benötigten Scopes im WWW-Authenticate-Header, und der Client kann einen Step-up-Autorisierungsflow starten. Die Spezifikation empfiehlt ausdrücklich, Scopes minimal zu halten; Sammelnamen wie *, all oder full-access führt sie unter den verbreiteten Anti-Patterns in Umsetzungen auf.

Was MCP nicht ist

MCP ist kein Modell. Es ist ein offener Standard, um KI-Anwendungen an externe Systeme anzubinden. Es enthält keine Gewichte, keine Inferenz-Engine und keine Festlegung zum Modellverhalten. Welches Modell Sie betreiben, liegt ausserhalb des Protokolls.

MCP ist kein Agenten-Framework. Die offizielle Anmerkung zum Geltungsbereich ist eindeutig: MCP befasst sich ausschliesslich mit dem Protokoll für den Austausch von Kontext und legt nicht fest, wie KI-Anwendungen LLMs einsetzen oder den bereitgestellten Kontext verwalten. Planung, Schleifensteuerung, Gedächtnis, Wiederholungslogik — all das liegt in Ihrer Anwendung, nicht im Protokoll.

MCP ist kein RAG-System. Die Dokumentation zu Resources sagt es direkt: Anwendungen greifen auf die Information zu und entscheiden selbst über ihre Verwendung — sei es durch Auswahl der relevanten Abschnitte, durch Suche mit Embeddings oder durch Übergabe des gesamten Inhalts an das Modell. Indexierung, Chunking und Vektorsuche sind nirgends im Protokoll definiert. Das sind Entscheidungen der Anwendung.

MCP ersetzt kein API-Gateway. Ein MCP-Server ist keine transparente Durchreiche vor Upstream-APIs. Das gegenüber der Upstream-Seite verwendete Access Token ist ein eigenes Token, ausgestellt vom dortigen Authorization Server, und der Server darf das empfangene Token nicht weiterreichen. Der Server trägt seine eigene Identität und seine eigene Autorisierungsgrenze. Rate Limiting, Kontingente, Protokollübersetzung und Edge-Routing bleiben Aufgaben des Gateways.

Der offizielle Vergleich ist treffend: Stellen Sie sich MCP wie einen USB-C-Anschluss für KI-Anwendungen vor. Der Anschluss legt nicht fest, was am anderen Ende des Kabels hängt oder was das angeschlossene Gerät mit der Verbindung macht.

Wo der Server in einer On-Premise-Installation steht

Der Sicherheitsabschnitt der Spezifikation nennt vier Prinzipien: Zustimmung und Kontrolle durch den Nutzer, Datenschutz, Tool-Sicherheit und Kontrollen für LLM-Sampling. Derselbe Abschnitt fügt eine Einschränkung an: MCP kann diese Prinzipien auf Protokollebene nicht durchsetzen, das wird von den Implementierenden erwartet. Diese eine Einschränkung erklärt, warum architektonische Entscheidungen hier so viel Gewicht tragen. Der grösste Teil der Kontrolle liegt nicht im Protokoll, sondern darin, wer den Server betreibt und wo er läuft.

Die Sicherheitsanforderungen der Spezifikation machen den Betrieb On-Premise zur naheliegenden Wahl. Lokal laufende Server sollten sich nur an 127.0.0.1 binden statt an alle Schnittstellen. Server mit Streamable HTTP müssen den Origin-Header prüfen und bei einem ungültigen Wert 403 zurückgeben — das ist der Schutz gegen DNS-Rebinding. Für alle Verbindungen wird Authentifizierung empfohlen. Ein lokaler Server ist ein Prozess, der Code auf dem Host-Rechner ausführt: Die Spezifikation empfiehlt, dass der Client diesen Prozess in einer Sandbox mit minimalen Standardrechten ausführt und dass ein lokal laufender Server den Zugang auf stdio oder einen eingeschränkten IPC-Kanal wie einen Unix Domain Socket begrenzt. MCP-Clients, die OAuth-Discovery-URLs abrufen, sollten Anfragen an private und reservierte IP-Bereiche blockieren, und serverseitige MCP-Client-Installationen sollten einen Egress-Proxy in Betracht ziehen — das ist der Teil, der Server-Side Request Forgery abdeckt, also den Fall, dass ein Server einen Client auf interne Netzadressen lenkt. Proxy-Server mit statischer Client-ID müssen für jeden dynamisch registrierten Client eine eigene Zustimmung des Nutzers einholen — die Regel, die den Confused-Deputy-Fall schliesst. Die Token-Audience-Isolation sagt in anderem Vokabular bereits dasselbe: Der Server ist die Grenze.

Zusammengenommen ergibt sich dieses Bild: Der MCP-Server ist die Stelle, an der Unternehmensdaten und Unternehmensaktionen vorbeikommen. Selbst wenn das Modell anderswo läuft, bestimmt der Server, welche Tools existieren, welche Ressourcen lesbar sind und mit welcher Identität welcher Aufruf nach Upstream geht. Sitzt dieser Server in Ihrem Netz und unter Ihrer Kontrolle, bleiben all diese Entscheidungen an einem Ort, den Sie prüfen können. Die Spezifikation hält zudem fest, dass Tool-Beschreibungen und Annotationen als nicht vertrauenswürdig gelten sollten, solange sie nicht von einem vertrauenswürdigen Server stammen — und wer definiert, was vertrauenswürdig ist, zieht damit die Grenze.

Der kürzeste Weg, MCP einzuordnen: Der grösste Teil des Codes, den man früher schrieb, um ein Modell an ein Unternehmenssystem anzubinden, hatte nie mit dem Modell zu tun. Es ging um Discovery, Schemata, Identität, Autorisierung, Antwortformate im Ausnahmefall und den Lebenszyklus. MCP standardisiert genau diesen Teil und hält sich aus dem Rest heraus. Deshalb sind die Entwurfsfragen für einen MCP-Server auch keine Protokollfragen: welche Aktionen zu Tools werden, welche Daten als Resources lesbar werden und welche Identität mit welchem Scope welches Upstream-System erreicht. Das Protokoll klärt, wo diese Fragen gestellt werden. Sie zu beantworten bleibt Architekturarbeit.

Quellen

• Model Context Protocol — specification, 2025-11-25 revision
• MCP specification — Authorization section (OAuth 2.1 roles, RFC 9728, error codes)
• MCP specification — Versioning and feature lifecycle
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• MCP Blog — MCP joins the Agentic AI Foundation (9 December 2025)
• Anthropic — Introducing the Model Context Protocol (25 November 2024)