Wie MCP zum USB-C der AI-Integration wurde — ein technischer Deep Dive
Engineering Team
Das N x M Integrationsproblem
Bevor das Model Context Protocol existierte, war die Verbindung von AI-Modellen mit externen Tools eine Uebung in kombinatorischer Explosion. Jede AI-Anwendung (Claude, GPT, Gemini, Copilot) benoetigte eine individuelle Integration fuer jedes Tool (Slack, Jira, GitHub, Datenbanken, APIs). Bei M AI-Anwendungen und N Tools benoetigte die Branche M x N individuelle Adapter — jeder mit eigenem Authentifizierungsablauf, Datenformat, Fehlerbehandlung und Wartungsaufwand.
Bedenken Sie die Groessenordnung: Bis 2025 gab es etwa 20 grosse AI-Anwendungsplattformen und Hunderte von Enterprise-Tools. Die Rechnung ging nicht auf. Jede neue AI-Plattform musste Integrationen von Grund auf neu aufbauen. Jedes neue Tool musste Adapter fuer jede AI-Plattform schreiben. Es war dasselbe Problem, das die Hardware-Branche vor USB hatte: Jedes Geraet hatte seinen eigenen proprietaeren Anschluss, und jeder Computer brauchte andere Ports.
MCP loest dies auf dieselbe Weise, wie USB-C das Anschlussproblem geloest hat: Standardisierung der Schnittstelle. Mit MCP implementiert jede AI-Anwendung einen MCP Client und jedes Tool einen MCP Server. Das M x N Problem wird zu M + N. Ein Protokoll, universelle Kompatibilitaet.
Protokollarchitektur: JSON-RPC, Capabilities und die drei Primitive
MCP basiert auf JSON-RPC 2.0, demselben leichtgewichtigen RPC-Protokoll, das vom Language Server Protocol (LSP) verwendet wird, das jeden modernen Code-Editor antreibt. Dies war eine bewusste Designentscheidung: JSON-RPC ist einfach, gut verstanden, sprachunabhaengig und kampferprobt.
Faehigkeitsverhandlung
Eine MCP-Verbindung beginnt mit einem initialize-Handshake, bei dem Client und Server gegenseitig ihre Faehigkeiten deklarieren. Dies ermoeglicht eine anmutige Weiterentwicklung des Protokolls. Neue Funktionen werden als neue Capability-Flags hinzugefuegt, und aeltere Clients oder Server koennen unbekannte Capabilities ignorieren.
Die drei Primitive
MCP definiert drei Kern-Primitive:
-
Tools: Funktionen, die das AI-Modell aufruft. Ueber tools/list entdeckt und ueber tools/call ausgefuehrt. Jedes Tool hat einen Namen, eine Beschreibung und ein in JSON Schema definiertes Eingabeschema.
-
Resources: Daten, die das AI-Modell liest. Durch URIs identifiziert und ueber resources/read abgerufen. Umfasst Dateien, Datenbankeintraege, API-Antworten usw.
-
Prompts: Wiederverwendbare Prompt-Vorlagen, die der Server bereitstellt. Ueber prompts/list entdeckt und ueber prompts/get abgerufen. Standardisieren, wie die AI domaenenspezifische Aufgaben des Servers angeht.
Vergleich mit Function Calling und OpenAPI
Um die Position von MCP zu verstehen, vergleichen wir es mit zwei grossen Alternativen.
MCP vs Function Calling
Function Calling (verwendet von OpenAI, Anthropic und anderen) bettet Tool-Definitionen inline in jede API-Anfrage ein. Entwickler beschreiben Tools als JSON Schemas, und das LLM waehlt, welches Tool mit welchen Parametern aufgerufen wird.
| Aspekt | Function Calling | MCP |
|---|---|---|
| Tool-Definition | Inline in der API-Anfrage | Auf externem Server definiert |
| Entdeckung | Keine (vom Entwickler bereitgestellt) | Dynamisch (Entdeckung ueber tools/list) |
| Zustand | Zustandslos (pro Anfrage) | Zustandsbehaftet (sitzungsbasiert) |
| Transport | HTTPS-API-Aufrufe | stdio, SSE, Streamable HTTP |
| Standardisierung | Anbieterspezifisch | Offener Standard |
| Mehrere Tools | Manuelle Orchestrierung | Protokollnativ |
MCP vs OpenAPI
OpenAPI (frueher Swagger) ist eine Spezifikation zur Beschreibung von REST-APIs. AI kann direkt OpenAPI-Spezifikationen lesen und API-Aufrufe generieren, aber es gibt wichtige Unterschiede.
| Aspekt | OpenAPI | MCP |
|---|---|---|
| Zweck | REST-API-Dokumentation | AI-Tool-Kommunikation |
| AI-Optimierung | Keine (allgemein) | Fuer AI-Interaktion konzipiert |
| Sitzungsverwaltung | Keine | Eingebaut |
| Typsicherheit | JSON Schema | JSON Schema + Laufzeitvalidierung |
| Ressourcenmodell | URL + HTTP-Methode | URI + Ressourcentyp |
Adoptions-Timeline
Verfolgen wir die Entwicklung von MCP:
- November 2024: Anthropic veroeffentlicht MCP als Open Source. Die erste Version unterstuetzt nur den stdio-Transport.
- Q1 2025: Claude Desktop, Cursor und Windsurf integrieren MCP-Unterstuetzung. Die Entwickler-Community waechst rasch.
- Q2 2025: SSE-Transport wird hinzugefuegt. Remote-MCP-Server werden praktikabel.
- Q3 2025: OpenAI kuendigt MCP-Unterstuetzung an. Google DeepMind integriert einen MCP Client in Gemini.
- Q4 2025: Streamable HTTP-Transport wird veroeffentlicht. Enterprise-Adoption beschleunigt sich.
- Q1 2026: Microsoft uebernimmt MCP in seine Copilot-Plattform. MCP Registry (offizieller Server-Katalog) wird gestartet.
- Q2 2026: MCP wird zum De-facto-Standard fuer AI-Tool-Kommunikation. Ueber 1.000 offizielle Server sind in der Registry registriert.
Die Zukunft der Agent-zu-Agent-Kommunikation
Die naechste Evolution von MCP ist die Agent-zu-Agent-Kommunikation (A2A). Derzeit definiert MCP die Kommunikation zwischen AI-Anwendungen (Host) und externen Tools (Server), aber die Faehigkeit von AI-Agenten, direkt miteinander zu kommunizieren, befindet sich noch in einem fruehen Stadium.
Zukunftsvision:
- Agenten stellen MCP-Server bereit: Jeder AI-Agent hat seinen eigenen MCP-Server, der von anderen Agenten als verfuegbare Tools entdeckt und aufgerufen werden kann
- Multi-Agent-Orchestrierung: Ein MCP-Gateway verwaltet die Aufgabendelegation und den Datenfluss zwischen mehreren Agenten
- Standardisiertes Delegationsprotokoll: Ein standardisierter Weg fuer Agenten, komplexe Aufgaben in Teilaufgaben zu zerlegen und an spezialisierte Agenten zu delegieren
FAQ
F: Steht MCP in Beziehung zum LSP (Language Server Protocol)? A: Ja. MCP ist vom LSP inspiriert. Beide verwenden JSON-RPC 2.0, nutzen das Capability-Negotiation-Muster und folgen einer Client-Server-Architektur. So wie das LSP Code-Editoren von der Programmiersprachen-Unterstuetzung entkoppelt hat, entkoppelt MCP AI-Anwendungen von der Tool-Integration.
F: Welche Sicherheitsrisiken bestehen beim Bereitstellen eines MCP-Servers? A: Zu den Hauptrisiken gehoeren Authentifizierungsumgehung, Tool-Missbrauch, Datenlecks und Denial-of-Service. OAuth 2.0-Authentifizierung, Eingabevalidierung, Ratenbegrenzung, Autorisierung auf Tool-Ebene und Audit-Logging aller Tool-Aufrufe sind essentielle Gegenmassnahmen.
F: Kann man eine bestehende REST-API in einen MCP-Server umwandeln? A: Ja. Das gaengige Muster besteht darin, jeden API-Endpunkt als MCP-Tool zu wrappen. Es gibt auch Tools zur automatischen Generierung von MCP-Servern aus OpenAPI-Spezifikationen.
F: Wie gross ist der Performance-Overhead von MCP? A: Der Overhead des JSON-RPC-Protokolls ist minimal. Beim stdio-Transport im Mikrosekundenbereich, beim HTTP-Transport vergleichbar mit einer normalen HTTP-Anfrage. Der Engpass liegt normalerweise in der Tool-Ausfuehrung selbst (Datenbankabfrage, API-Aufruf).
F: Gibt es eine Groessenbeschraenkung fuer MCP-Nachrichten? A: Das Protokoll selbst hat keine Groessenbeschraenkung. Praktische Grenzen haengen vom Transport und der Infrastruktur ab. Fuer Produktions-Deployments halten Sie einzelne Tool-Antworten unter 10 MB und verwenden Paginierung oder Streaming fuer grosse Datensaetze.