Woher MCP kommt und welches Problem es löst
Anthropic veröffentlichte Model Context Protocol am 25. November 2024. Ziel war es, viele individuelle Integrationen durch einen offenen Weg zu ersetzen, über den KI-Assistenten auf Content-Repositories, Geschäftswerkzeuge und Entwicklungsumgebungen zugreifen können. [1]
MCP ersetzt keine Datenbanken oder REST-APIs. Ein MCP-Server liegt normalerweise über einem bestehenden System und beschreibt dessen Fähigkeiten für kompatible KI-Hosts. [1][4]
Was MCP standardisiert und was nicht
MCP standardisiert Discovery und Aufruf von Tools, die Bereitstellung von Resources und wiederverwendbaren Prompt-Vorlagen. Ein Host muss daher nicht jede private API einzeln kennen. [4][5][6][7]
Geschäftslogik, Datenmodell und unternehmensspezifische Berechtigungen bleiben Sache der Implementierung. [5][8]
Architektur in der Praxis: Host, Client und Server
| Element | Rolle |
|---|---|
| Host | KI-Anwendung, die Modell, Nutzer und MCP-Verbindungen koordiniert. |
| MCP-Client | Protokollschicht für die Kommunikation mit einem bestimmten Server. |
| MCP-Server | Stellt Fähigkeiten bereit und verbindet sie mit externen Daten oder Systemen. |
| Tools | Vom Modell aufrufbare Aktionen. |
| Resources | Daten und Kontext mit URI. |
| Prompts | Wiederverwendbare Prompt-Vorlagen. |
Die klassische MCP-Architektur trennt Host, Client und Server. Der Host ist die KI-Anwendung, der Client implementiert die Protokollkommunikation, der Server stellt Daten und Operationen bereit. Im aktuellen Release bleibt diese Aufgabenteilung bestehen, während HTTP-Protokollzustand nicht mehr zwischen Requests gespeichert werden muss. [15][2]
Ein Host kann gleichzeitig mehrere MCP-Server anbinden, etwa GitHub, ein Ticketsystem und eine interne Wissensbasis. Der Host entscheidet, welche Fähigkeiten Modell und Nutzer sehen. [12][15]
Tools, Resources und Prompts: die Kernbausteine
`Tools` sind Aktionen, die das Modell auslösen kann, etwa eine Bestellung suchen, ein Issue erstellen oder eine Berechnung durchführen. Die Spezifikation definiert Name, Beschreibung und Input-Schema. [5]
`Resources` stellen Daten per URI bereit, zum Beispiel Dateien, Datenbankschemata oder Dokumentation. `Prompts` liefern wiederverwendbare Prompt-Vorlagen. [6][7]
STDIO, Streamable HTTP und der alte SSE-Transport
| Transport | Typischer Einsatz |
|---|---|
| STDIO | Lokaler Prozess, CLI, IDE, Entwicklerwerkzeuge. |
| Streamable HTTP | Entfernter Server, SaaS, Produktionsinfrastruktur. |
| HTTP+SSE | Alter HTTP-Transport; seit 2026-07-28 deprecated. |
STDIO eignet sich für lokale Server, die vom Client als Prozess gestartet werden. Streamable HTTP ist für entfernte Netzwerkdienste gedacht. [4][2]
Seit `2026-07-28` ist der Remote-Kern zustandslos. Legacy HTTP+SSE ist offiziell deprecated und besitzt mindestens zwölf Monate Übergangszeit. [2]
So sieht ein Tool-Aufruf im aktuellen MCP aus
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {"q": "invoice 2026"}
}
}Seit `2026-07-28` gibt es keinen verpflichtenden `initialize`-Austausch und kein `Mcp-Session-Id`. Ein Request kann Version, Client-Informationen und Capabilities tragen; optional liefert `server/discover` vorab Serverfähigkeiten. [2]
Bei Streamable HTTP ermöglichen `Mcp-Method` und `Mcp-Name` Routing und Metering in Gateways, WAFs und Rate Limitern ohne Parsing des gesamten JSON-Bodys. [2]
Praxisbeispiel: Agent mit einem Ticketsystem
Ein internes Ticketsystem kann `search_tickets`, `get_ticket` und `update_ticket` als Tools anbieten, Prozessdokumentation als Resources und einen Prompt für Incident-Analyse. Der Host entdeckt den Katalog, das Modell wählt ein Tool und der Server übersetzt den Aufruf in die private API. [5][6][7]
Der Vorteil ist Wiederverwendung: derselbe MCP-Server kann mehrere kompatible Hosts bedienen. [4][12]
Autorisierung: OAuth 2.1, Bearer Tokens und Client ID Metadata Documents
Für HTTP basiert MCP-Autorisierung auf OAuth-2.1-Konzepten und Discovery-Standards. Geschützte MCP-Server sind Resource Server, MCP-Clients OAuth-Clients; Access Tokens gehen im Header `Authorization: Bearer`. Query Strings sind dafür verboten. [8]
Audience Validation und PKCE sind Teil der Sicherheitsanforderungen. Dynamic Client Registration ist 2026 offiziell zugunsten von Client ID Metadata Documents deprecated. [2][8]
Sicherheit: MCP bedeutet nicht vollständiges Vertrauen
Server müssen Tool-Eingaben validieren, Zugriffskontrollen umsetzen, Aufrufe begrenzen und Ergebnisse bereinigen. Clients sollten sensible Aktionen bestätigen lassen, Tool-Argumente zeigen, Timeouts setzen und Aufrufe auditieren. [5]
Least Privilege bleibt zentral. Ein Dokumentationsserver braucht keine Rechte zum Löschen von Produktionsdaten. [5][8][13]
MCP Apps: wenn ein Tool eine Oberfläche braucht
MCP Apps ist eine offizielle Erweiterung für interaktive UIs wie Formulare, Dashboards und Visualisierungen. Ein Tool verweist auf eine `ui://`-Resource, die ein Host in einem sandboxed iframe rendern kann. [9]
UI-Kommunikation bleibt strukturiert und auditierbar; Hosts können Zustimmung für UI-initiierte Tool-Aufrufe verlangen. [9]
Tasks: lange Operationen ohne dauerhafte Verbindung
MCP Tasks ist für Operationen gedacht, die Sekunden, Minuten oder Stunden dauern. Statt die Verbindung zu blockieren, liefert der Server einen stabilen Task-Handle, dessen Status der Client später abfragt. [10]
Typische Fälle sind CI, Batch-Jobs, Deployments, externe Queues und Human-in-the-loop-Prozesse. [10][2]
Adoption: Anthropic, OpenAI, GitHub und Entwicklerwerkzeuge
OpenAI integrierte Remote-MCP-Server im Mai 2025 in die Responses API und trat dem MCP Steering Committee bei. [11]
GitHub Copilot unterstützt MCP in IDEs, Copilot CLI, Copilot App und Cloud Agent und bietet Registry- sowie Enterprise-Verwaltung. [12][13][14]
MCP vs REST API und Function Calling
REST beschreibt allgemeine System-APIs, Function Calling den Funktionsaufruf eines bestimmten Modells. MCP ergänzt eine gemeinsame Discovery-, Schema- und Kommunikationsschicht zwischen KI-Host und Tool-Server. [4][5]
Bei einem Modell und wenigen internen Funktionen kann MCP unnötig sein. Für mehrere Hosts oder eine wiederverwendbare Integration ist der Nutzen deutlich größer. [4][11][12]
Checkliste für einen produktiven MCP-Server
Produktive Server sollten mit wenigen klar definierten Tools starten. Jedes Tool braucht einen präzisen Namen, eine eindeutige Beschreibung, validiertes Input-Schema und minimale Berechtigungen. [5][8]
Remote-Server sollten aktuelles Streamable HTTP, Authorization, Metriken, Rate Limiting und Tracing einsetzen und Kompatibilität bewusst planen. [2][8]
- Für Spezifikation `2026-07-28` entwickeln.
- Tool-Fläche und Rechte klein halten.
- Alle Argumente und Ergebnisse validieren.
- Sensible Aktionen bestätigen lassen.
- Bei HTTP OAuth und Audience-Validierung korrekt umsetzen.
- Rate Limits, Timeouts, Audit-Logs und Tracing nutzen.
- Keine unnötigen Secrets an Server geben.
- Host-Kompatibilität und Fehlerfälle testen.
Was sich 2026 geändert hat und wohin MCP geht
`2026-07-28` brachte den zustandslosen Kern, entfernte Handshake und Protokollsitzungen, machte Listen cachebar, führte Header-Routing und ein formales Extensions-System ein und stärkte Authorization. Roots, Sampling und Logging sind für neue Implementierungen deprecated. [2]
Die Roadmap von August 2026 priorisiert Agent Messaging, Webhooks und Events, HTTP-Vereinheitlichung, Agent Identity, Enterprise Security und bessere SDK-Erfahrung. Das sind Entwicklungsrichtungen, nicht vollständig verfügbare Funktionen. [3]
