MCP-Architektur

Wissen

MCP folgt einer klaren Schichten-Architektur. Jede Schicht hat eine definierte Aufgabe. Wenn du diese Architektur verstehst, kannst du MCP-Integrationen debuggen, optimieren und selbst bauen.

Überblick: Host -> Client -> Transport -> Server

+------------------------------------------+
|  HOST (z.B. Claude Desktop, Cursor)      |
|                                          |
|  +------------------------------------+  |
|  |  CLIENT (MCP Client Library)       |  |
|  |                                    |  |
|  |  +------------------------------+  |  |
|  |  |  TRANSPORT (stdio / HTTP)    |  |  |
|  |  +------------------------------+  |  |
|  +------------------------------------+  |
+------------------------------------------+
              |  JSON-RPC 2.0  |
              v                v
+------------------------------------------+
|  SERVER (z.B. GitHub MCP, Jira MCP)      |
|                                          |
|  - Tools     (Funktionen ausführen)     |
|  - Resources (Daten bereitstellen)       |
|  - Prompts   (Templates anbieten)        |
+------------------------------------------+

Schicht 1: Host

Der Host ist die Anwendung, in der du arbeitest -- also Claude Desktop, Cursor, VS Code oder ChatGPT. Der Host ist verantwortlich für:

• Benutzeroberfläche -- Zeigt Ergebnisse an und nimmt Eingaben entgegen
• Sicherheit -- Entscheidet, welche MCP-Server verbunden werden dürfen
• Lebenszyklusverwaltung -- Startet und stoppt MCP-Clients

Ein Host kann mehrere Clients gleichzeitig verwalten -- zum Beispiel einen für GitHub und einen für Jira.

Schicht 2: Client

Der Client ist die Brücke zwischen Host und Server. Er:

• Hält eine 1:1-Verbindung zu genau einem Server
• Verwaltet die Capability Negotiation -- welche Features der Server bietet
• Kümmert sich um das Message-Routing zwischen Host und Server

Schicht 3: Transport

Der Transport regelt, wie die Nachrichten physisch übertragen werden. MCP unterstützt zwei Transportwege:

stdio ist der häufigste Transportweg für lokale Entwicklung. Der Host startet den Server als Kindprozess und kommuniziert über stdin/stdout.

SSE wurde für Remote-Server genutzt, ist aber mittlerweile deprecated. Der empfohlene Nachfolger ist Streamable HTTP, der bidirektionale Kommunikation über einen einzelnen HTTP-Endpoint ermöglicht.

Schicht 4: Server

Der Server stellt die eigentlichen Fähigkeiten bereit. Er exponiert:

• Tools -- Funktionen, die das LLM aufrufen kann (z.B. "erstelle ein Jira-Ticket")
• Resources -- Daten, die das LLM lesen kann (z.B. "aktueller Sprint-Status")
• Prompts -- Vordefinierte Prompt-Templates (z.B. "Code-Review für PR #123")

Mehr zu diesen drei Primitives im nächsten Abschnitt.

Verstehen

Das Protokoll: JSON-RPC 2.0

MCP nutzt JSON-RPC 2.0 als Nachrichtenformat. Das ist ein leichtgewichtiges Remote-Procedure-Call-Protokoll, das sich ideal für die Kommunikation zwischen KI und externen Diensten eignet.

Nachrichten-Typen

Es gibt drei Typen von JSON-RPC-Nachrichten:

1. Request -- Der Client fragt den Server nach etwas:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Bug im Login",
      "priority": "high"
    }
  }
}

2. Response -- Der Server antwortet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Issue PROJ-456 erstellt"
      }
    ]
  }
}

3. Notification -- Einweg-Nachricht ohne Antwort:

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progressToken": "abc",
    "progress": 50,
    "total": 100
  }
}

Der Verbindungsaufbau

Wenn ein Host einen MCP-Server verbindet, läuft folgender Prozess ab:

1. Initialize -- Client sendet initialize-Request mit seinen Capabilities
2. Server antwortet -- Server meldet seine Capabilities (welche Tools, Resources, Prompts er bietet)
3. Initialized -- Client bestätigt mit notifications/initialized
4. Betrieb -- Nachrichten fließen in beide Richtungen

Client                          Server
  |                               |
  |-- initialize ----------------->|
  |                               |
  |<-- initialize (response) -----|
  |                               |
  |-- notifications/initialized -->|
  |                               |
  |== Verbindung aktiv ===========|
  |                               |
  |-- tools/list ----------------->|
  |<-- tools/list (response) -----|
  |                               |
  |-- tools/call ----------------->|
  |<-- tools/call (response) -----|

Anwenden

Reflektieren

Die MCP-Architektur folgt dem Prinzip der Einfachheit: Host, Client, Transport, Server und JSON-RPC 2.0 als Protokoll. Diese klare Trennung macht MCP leicht zu implementieren und universell einsetzbar. Im nächsten Abschnitt lernst du die drei Primitives kennen.