Model Context Protocol (MCP)

Was ist das Model Context Protocol (MCP)?

Das Model Context Protocol (MCP) ist ein offenes Protokoll, das standardisiert, wie KI-Anwendungen auf Kontext und Fähigkeiten außerhalb des Modells zugreifen. Vor MCP brauchte jede Kombination aus KI-Anwendung und Tool eine eigene Integration: Ein Coding-Assistent hatte ein Plug-in für den Issue-Tracker, ein Chat-Assistent ein anderes für dasselbe System. MCP ersetzt das durch eine gemeinsame Schnittstelle. Ein Tool oder eine Datenquelle wird einmal als MCP-Server bereitgestellt und kann dann von jeder MCP-fähigen Anwendung genutzt werden.

Anthropic hat MCP im November 2024 als Open-Source-Projekt vorgestellt. Das Protokoll verbreitete sich schnell bei KI-Anbietern, IDEs und Entwicklerwerkzeugen. Im Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation, einen Fonds unter dem Dach der Linux Foundation; seitdem wird das Protokoll herstellerneutral weiterentwickelt. Die Spezifikation orientiert sich am Language Server Protocol und erscheint auf modelcontextprotocol.io in datierten Versionen.

Architektur: Hosts, Clients und Server

MCP unterscheidet drei Rollen:

• Host: die KI-Anwendung, mit der die Nutzerin oder der Nutzer arbeitet, etwa eine IDE, ein Desktop-Assistent oder die Laufzeitumgebung eines KI-Agenten.
• Client: ein Konnektor innerhalb des Hosts, der mit genau einem Server kommuniziert.
• Server: ein Programm, das Fähigkeiten bereitstellt, zum Beispiel Zugriff auf eine Datenbank, ein Ticketsystem oder eine Observability-Plattform.

Nachrichten werden als JSON-RPC 2.0 kodiert. Die Spezifikation definiert zwei Standard-Transporte: stdio, bei dem der Client den Server als lokalen Unterprozess startet, und Streamable HTTP für entfernte Server. Remote-Server werden in der Regel über einen in der Spezifikation beschriebenen, OAuth-basierten Autorisierungsablauf geschützt.

Grundbausteine: Tools, Resources und Prompts

Ein MCP-Server kann drei Arten von Fähigkeiten anbieten:

• Tools sind Funktionen, die das Modell selbst aufrufen kann, etwa search_errors oder run_query. Jedes Tool hat einen Namen, eine Beschreibung und ein JSON-Schema für die Eingabe.
• Resources sind Kontext und Daten, zum Beispiel Dateien, Datenbankschemata oder Dokumente, adressiert über eine URI.
• Prompts sind wiederverwendbare, parametrisierte Nachrichtenvorlagen, die Nutzer auswählen können.

Der Host listet die verfügbaren Tools auf, gibt ihre Beschreibungen an das Modell weiter und führt die Aufrufe aus, die das Modell anfordert. Das Ergebnis fließt zurück in die Konversation, sodass das Modell damit weiterarbeiten oder das nächste Tool aufrufen kann.

Beim Verbindungsaufbau einigen sich beide Seiten auf die Protokollversion und die unterstützten Fähigkeiten. So bleiben Clients und Server kompatibel, während sich die Spezifikation weiterentwickelt: Ein Server kann neue Tools ergänzen, und der Client erkennt sie ohne Codeänderung. Offizielle SDKs gibt es für mehrere Sprachen, darunter Python und TypeScript. Ein einfacher Server, der eine interne API kapselt, umfasst daher oft nur wenige Dutzend Zeilen Code.

Zur Einordnung: MCP ersetzt weder REST-APIs noch das Function Calling der Modellanbieter. Es standardisiert die Ebene dazwischen, also wie eine Anwendung Tools findet, beschreibt und aufruft, unabhängig davon, welches Modell im Hintergrund arbeitet.

Beispiel: ein Observability-MCP-Server in der IDE

Ein illustratives Szenario: Ein Entwickler fragt seinen Coding-Agenten, warum Checkout-Anfragen seit heute Morgen langsam sind. Der Agent sieht, dass ein Observability-MCP-Server die Tools find_slow_traces und list_deployments anbietet. Er ruft das erste Tool für den Endpunkt POST /checkout auf, erhält die langsamsten Traces mit den dominierenden Spans, ruft dann das zweite Tool auf und findet ein Deployment kurz vor dem Latenzanstieg. Mit diesen Belegen öffnet er den betroffenen Code und schlägt eine Korrektur vor, ohne dass der Entwickler Daten zwischen Tools kopieren muss.

Sicherheit und Governance

MCP gibt Modellen Zugriff auf echte Systeme. Die Spezifikation betont deshalb Einwilligung der Nutzer und sichere Tool-Nutzung. In der Praxis wichtig:

• Least Privilege: Jeder Server erhält nur die nötigen Berechtigungen, möglichst nur Lesezugriff.
• Tool-Ausgaben und Tool-Beschreibungen gelten als nicht vertrauenswürdig. Inhalte eines Servers können Prompt Injection enthalten, und ein bösartiger Server kann seine Tools irreführend beschreiben.
• Menschliche Freigabe für Tools mit Seiteneffekten und eine Allowlist vertrauenswürdiger Server.
• Audit-Logging jedes Tool-Aufrufs mit Nutzer, Server, Argumenten und Ergebnisstatus.

MCP-Aufrufe überwachen

Agenten verketten viele Tool-Aufrufe, deshalb gehören MCP-Aufrufe in denselben Trace wie die LLM-Aufrufe, die sie ausgelöst haben. Die OpenTelemetry GenAI Semantic Conventions enthalten Konventionen für MCP, derzeit noch im Status „Development“, mit Attributen wie mcp.method.name und Metriken wie mcp.client.operation.duration. So sehen Sie, welche Tools langsam sind, welche fehlschlagen und wie oft ein Agent sie pro Aufgabe aufruft.

Wie Obseria hilft

Obseria arbeitet auf beiden Seiten von MCP. Der Obseria MCP-Server gibt Coding-Agenten lesenden, eingeschränkten Zugriff auf Fehler, Traces, Logs und Deployments; jeder Tool-Aufruf landet im Audit-Log. Mit AI Observability erscheinen MCP- und LLM-Aufrufe Ihrer eigenen Agenten als OpenTelemetry-Traces mit Latenz, Fehlern und Token-Verbrauch.