MCP (Model Context Protocol)

1. Konzeptüberblick und systemisches Problem

Vor der Einführung des MCP-Protokolls litt das Ökosystem für agentische Tools unter dem klassischen $N \times M$-Kompatibilitätsproblem:

1. Fragmentierung der Adapter: Wenn Sie 5 AI-Clients (Cursor, Claude Desktop, Continue, ein interner CLI-Agent, eine Web-Oberfläche) und 10 Datenquellen (PostgreSQL, GitHub, Slack, Sentry, lokales Dateisystem) haben, mussten Ingenieure 50 separate Integrations-Konnektoren erstellen und warten.
2. Leckage sensibler Schlüssel: Client-Anwendungen erforderten die Übertragung direkter API-Tokens in ihren Kontext, was die Angriffsfläche erhöhte.
3. Fehlende einheitliche Typisierung von Ressourcen: Es gab keinen Standard dafür, wie ein Modell passive Daten (Dokumente zum Lesen) getrennt von aktiven Aktionen mit Nebenwirkungen (Datenbank-Mutationen) erhalten sollte.

Das Model Context Protocol (MCP) löst dieses Problem analog zum Language Server Protocol (LSP) in der IDE-Welt: Es ist das „USB-C für künstliche Intelligenz“, das die Interaktion zwischen AI-Clients und Backend-Tools über ein offenes JSON-RPC 2.0-Protokoll vereinheitlicht.

2. Architektonische Taxonomie und mentales Modell

Das MCP-Protokoll basiert auf einer klaren Client-Server-Aufteilung und operiert mit drei primären Primitiven:

• 1. Tools (Aktive Instrumente mit Nebenwirkungen): Ausführbare Funktionen, die das Modell aufrufen kann, um den Zustand der Außenwelt zu ändern (Ausführen einer SQL-Abfrage, Starten eines Builds, Senden eines Kommentars an GitHub). Sie werden durch strenge JSON Schema-Beschreibungen definiert.
• 2. Resources (Passive Datenquellen zum Lesen): URI-adressierte Daten ohne Nebenwirkungen, die als Dokumente in den Modellkontext übergeben werden (Dateiinhalte, Server-Logs, Tabellenschemas, Dokumentation).
• 3. Prompts (Interaktionsvorlagen): Vorab parametrisierte Prompts und Kontextketten, die der Server dem Client anbietet (z. B. eine fertige Anleitung für einen Sicherheitsaudit oder die Generierung einer Migration).
• 4. Transport Layer:
  • stdio: Start des Servers als Child-Prozess auf derselben Maschine. Erfordert keine Netzwerkports und hat nahezu null Latency-Overhead.
  • SSE (Server-Sent Events): Betrieb über HTTP/HTTPS, was die Anbindung entfernter Enterprise-Microservices und Cloud-Agenten ermöglicht.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus einer Sitzung nach dem MCP-Protokoll durchläuft vier Phasen:

1. Handshake & Capabilities Negotiation (Aushandlung): Der Client sendet eine initialize-Anfrage und deklariert dabei seine Fähigkeiten (z. B. Unterstützung von Benachrichtigungen oder Root-Folders). Der Server antwortet mit einer Liste seiner Fähigkeiten (Tools, Resources, Prompts) und der Protokollversion.
2. Dynamic Discovery (Dienst-Erkennung): Der Client fragt Manifeste über tools/list oder resources/list ab. Die erhaltenen Funktionsbeschreibungen und Parameter werden automatisch in das Function Calling-Format für das Ziel-LLM übersetzt.
3. Execution & Context Invocation (Aufruf der Aktion): Wenn das Modell einen Funktionsaufruf generiert, übersetzt der Client diesen in eine tools/call-Anfrage an den entsprechenden MCP-Server mit validierten JSON-Parametern.
4. Result Streaming & State Notification (Ergebnisrückgabe): Der Server führt die Aktion lokal aus, wobei er eigene sichere Konfigurationen nutzt (ohne Passwortweitergabe an den Client), und gibt das Ergebnis im Format Text, Bilder oder eingebettete Ressourcen zurück.

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Sicherer Zugriff auf Produktions-Datenbanken

Ein MCP-Server für PostgreSQL läuft innerhalb eines geschlossenen VPC-Kontexts. Er öffnet für Cursor oder Claude Code nur das Tool execute_read_only_query. Der Agent kann Schemata analysieren und langsame Abfragen optimieren, ohne direkten Zugriff auf das Datenbank-Passwort oder Löschrechte zu haben.

02. Einheitliches lokales Entwickler-Toolset

Ein einmal geschriebener MCP-Server für die Interaktion mit dem internen GitLab, Jira und dem Metrik-Dienst Datadog wird gleichzeitig an das CLI-Terminal (Claude Code), den grafischen Editor (Cursor) und automatisierte GitHub Actions angebunden.

03. Browser-Automatisierung mit Puppeteer/Playwright

Ein MCP-Server steuert einen Headless-Browser und stellt dem Client die Tools navigate_to, click_element und take_screenshot zur Verfügung. Der Agent testet Interfaces und validiert Designs eigenständig, ohne dass schwere externe Plugins installiert werden müssen.

5. Fallstricke, häufige Fehler und Sicherheit

• Kontextfenster-Blähung (Context Bloat): Das Verbinden von 15 MCP-Servern mit hunderten detaillierten JSON-Schemas kann mehr als 30.000 Tokens verbrauchen, noch bevor das erste Wort des Benutzers eingegeben wird. Verwenden Sie dynamische Filterung oder Lazy Loading von Tools (Dynamic Tool Selection).
• Gefahr durch Drittanbieter-Server (Arbitrary Code Execution): Ein lokaler MCP-Server wird mit den vollen Rechten Ihres OS-Kontos ausgeführt. Das Starten ungeprüfter Server via npx -y ohne Review des Quellcodes kann zum Diebstahl lokaler SSH-Keys führen.
• Verletzung des Protokollvertrags durch Logging: Die Verwendung von standardmäßigem console.log() oder print() innerhalb des Server-Codes korruptiert den stdout-Kanal beim stdio-Transport. Schreiben Sie Diagnoseausgaben ausschließlich in stderr.