Was ist MCP? Model Context Protocol, JSON-RPC, KI-Agenten und Tool Calling

Vorab: MCP (Model Context Protocol) ist kein anderer Name für Function Calling und auch kein Modell. Es ist ein offenes Protokoll zwischen einer KI-App (dem Host) und externen Tool-Prozessen (MCP Servers). Die Nachrichten sind JSON-RPC 2.0. Das Modell spricht weiter das Tool Calling / Function Calling des jeweiligen Anbieters. Der Host übersetzt tools/list in das tools-Array des Modells und danach tool_calls in tools/call. Diese drei Schichten zusammen sind der übliche Weg, wie KI-Agenten 2026 Tools aufrufen.

Dieser Artikel ist vom 7. September 2026. Die aktuelle Spezifikation ist 2026-07-28: keine Protokollsitzung, kein initialize-Handshake, jede Anfrage trägt _meta, und die Capability-Entdeckung läuft über server/discover. Unser August-Text Agent-JSON-Datenfluss zeigt noch das alte initialize-Beispiel; behandeln Sie diesen Leitfaden als den aktuellen Stand. Für „Muss ich Server-Code ändern?“ siehe den MCP-2026-Migrationsleitfaden.

Was MCP ist

Model Context Protocol ist ein offener Standard dafür, wie KI-Anwendungen externen Kontext entdecken, lesen und aufrufen. Anthropic hat es im November 2024 veröffentlicht; die Governance ging später an die Agentic AI Foundation. Es legt fest, wie Kontext ausgetauscht wird. Es legt nicht fest, welches Modell Sie nutzen, wie Sie einen mehrstufigen KI-Agenten orchestrieren oder wie Sie Geschäftslogik schreiben.

Denken Sie an USB-C: die Buchse ist Standard; ob Festplatte, Display oder Netzteil steckt, liegt außerhalb. MCP standardisiert die Buchse Host ↔ Server. Ein Dateisystem, GitHub, eine interne Bestell-API oder ein JSON-Validator wie diese Seite — das sind alles nur Server.

Zwei Schichten: die Datenschicht ist JSON-RPC 2.0 (Methoden, params, Fehlercodes, Notifications); die Transportschicht ist, wie diese JSON-Frames wandern — stdio auf derselben Maschine, Streamable HTTP remote. Wechseln Sie den Transport — die Nachrichtenform bleibt. Deshalb beginnt MCP-Debugging damit, zu trennen: „Der Umschlag ist JSON-RPC; die fachliche Payload ist oft ebenfalls JSON.“

Host, Client, Server

Das Dreieck der Spezifikation wird leicht mit dem Alltagsgespräch „Client / Server“ vermischt:

• Host: die KI-App, die der Nutzer geöffnet hat. Sie erzeugt Clients, reicht dem Modell die Tool-Schemas, autorisiert und validiert vor der Ausführung und schreibt Ergebnisse zurück in den Thread.
• Client: ein Verbindungsobjekt im Host. Ein Server, ein Client. Spricht VS Code mit einem Dateisystem und mit Sentry, sind das zur Laufzeit zwei Clients.
• Server: das Programm, das Kontext liefert. Es kann die Maschine mit dem Host teilen (stdio) oder woanders laufen (Streamable HTTP). „Server“ ist eine Rolle, keine Pflicht zu einem öffentlichen Hostnamen.

Das Modell sitzt nicht in diesem Dreieck. GPT-5.5, Claude 4.8 und Gemini 3.7 sehen das vom Host übersetzte tools-Array. Sie sehen kein JSON-RPC und kein Mcp-Session-Id (der Session-Header ist in 2026-07-28 weg). „Das Modell spricht MCP“ ist Marketing. In der Technik sitzt immer ein Host dazwischen.

JSON-RPC 2.0 lesen

JSON-RPC ist eine Konvention für Remote Procedure Calls mit JSON — näher an „eine Funktion aufrufen“ als REST. MCP hat es gewählt, weil Methodennamen stabil bleiben (tools/list, tools/call), die Dreiteilung Request / Response / Notification klar ist und der ganze Umschlag modellfreundliches JSON ist.

Ein tools/call nach Spezifikation 2026-07-28 sieht so aus. Hinweis: kein Handshake, kein Session-Header. Version und Client-Identität liegen in _meta, jede Server-Instanz kann den Frame verarbeiten.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

Eine Erfolgsantwort ist derselbe Umschlag. Das Geschäftsergebnis sitzt in result.content, oft type: "text", und dieser Text kann selbst ein JSON-String sein — Protokoll außen, Payload innen. Beim Debuggen zuerst id mit der Anfrage abgleichen, dann das innere Objekt gegen das Schema prüfen.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

Fehler nutzen das JSON-RPC-error-Objekt: code, message, optional data. 2026-07-28 hat „Ressource nicht gefunden“ vom MCP-eigenen -32002 auf das Standard--32602 (Invalid Params) umgestellt. Clients, die auf das alte Literal prüfen, übersehen den Fehler. Notifications haben keine id und erwarten keine Antwort — etwa eine Änderung der Tools-Liste.

Tools, Resources, Prompts

Ein Server kann drei Primitive bereitstellen. KI-Agenten arbeiten vor allem mit Tools; die anderen beiden werden leicht ausgelassen und sparen oft eine Runde Modellraten.

Ein Tool ist name, description und inputSchema. inputSchema ist JSON Schema (seit 2026-07-28: 2020-12; die Wurzel muss weiter type: "object" sein; oneOf / $ref / $defs sind erlaubt). Optionales outputSchema begrenzt die Rückgabeform. Hosts kopieren inputSchema fast 1:1 in parameters / input_schema der Modell-API.

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources passen zu „lesen, dann denken“: schema://order.v1 zu laden ist günstiger, als das Modell ein 200-zeiliges Schema im Thread auswendig lernen zu lassen. Prompts passen zu festen Team-Einstiegen. Roots, Sampling und Logging sind in 2026-07-28 deprecated: Workspace-Pfade als Tool-Argumente oder Resource-URIs übergeben; Server sollen den Host nicht um eine Completion bitten; Logs gehen nach stderr oder OpenTelemetry.

Wie es mit Tool Calling gestapelt wird

Drei Namen werden oft zu einem zusammengezogen. Sie liegen nicht auf derselben Schicht — der Artikel zum Agent-JSON-Datenfluss verfolgt jeden Hop. Hier nur die Abbildung:

Function Calling ist der frühe Name von OpenAI; Tool Calling ist der spätere generische Begriff (Claude tools, Gemini Function Calling, OpenAI Tools API). Für Entwickler ist es ein Ablauf: Der Host schickt ein Schema, das Modell gibt einen Aufruf mit JSON-Argumenten zurück, der Host führt ihn aus und schiebt ein JSON-Ergebnis zurück in den Thread.

MCP ersetzt diese Schicht nicht. Ein Host, der nur In-Process-Funktionen per Tool Calling aufruft, bleibt gültig. MCP macht Tools entdeckbar, prozessübergreifend und über Hosts hinweg wiederverwendbar. Unternehmens-KI-Agenten stapeln fast immer beide; Skripte und Demos lassen MCP oft weg.

Zwei Fallen bei der Abbildung: Modell-APIs liefern arguments oft als String; MCP params.arguments ist ein Objekt. Und der name aus tools/list muss unverändert zum Modell und zu tools/call — erfinden Sie dazwischen keinen „freundlicheren“ Alias. Validieren Sie vor dem echten tools/call; siehe Tool Calling und JSON-Schema-Validierung.

Ein vollständiger Tool-Aufruf

Der Nutzer sagt: „Validiere dieses Bestell-JSON mit order.v1.“ Nach 2026-07-28 ist der Pfad:

1. Host → Server: server/discover (cachefähig), um Tools zu bestätigen; oder die nächste Anfrage senden und bei Versionsfehler erneut versuchen.
2. Host → Server: tools/list liefert Einträge mit inputSchema; das Ergebnis kann ttlMs / cacheScope tragen.
3. Host → Modell: Liste auf tools[].parameters abbilden (weiterhin JSON Schema).
4. Modell → Host: tool_calls mit name validate_json; arguments ist oft JSON als String.
5. Host validiert: JSON.parse, dann inputSchema prüfen. Bei Fehler den Fehler als Tool-Ergebnis schreiben — den echten Server nicht anfassen.
6. Host → Server: tools/call mit Objekt-arguments und Protokollversion in _meta.
7. Server → Host: result.content; der Host kann outputSchema erneut prüfen.
8. Host → Modell: ein JSON-String mit role: tool; das Modell antwortet dem Nutzer oder startet eine weitere Tool-Runde.

User natural language
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── tools/call only after validation
    │
    ▼
result JSON ──► tool message ──► model’s final answer

Beim Remote-Transport müssen die HTTP-Header MCP-Protocol-Version, Mcp-Method und Mcp-Name enthalten und mit dem Body übereinstimmen, sonst soll der Server ablehnen. Load Balancer können nach Headern routen, ohne JSON zu parsen. Lokales stdio hat diese Header nicht; die JSON-RPC-Methodennamen sind dieselben.

Was Sie von 2026-07-28 merken sollten

Die Juli-Spezifikation ist die größte Revision seit dem Launch, und der 28. Juli 2026 ist das finale Veröffentlichungsdatum. Für „Was ist MCP“ reicht die Liste unten. Ob Ihr Server Code-Änderungen braucht, bleibt der Entscheidungsbaum im Migrationsartikel.

• Kein Handshake, keine Protokollsitzung: initialize / initialized und Mcp-Session-Id sind weg. Jede Anfrage ist in sich geschlossen. Verketten Sie Anwendungszustand mit einem expliziten basket_id (oder ähnlich) als normales Argument. Erwarten Sie nicht, dass der Transport Sie merkt.
• Entdeckung ist server/discover: optional, aber ein Aufruf liefert unterstützte Versionen, Capabilities und serverInfo. Listen-Ergebnisse tragen ttlMs; ein langer SSE-Stream ist nicht mehr der einzige Weg, zu erfahren, dass sich Tools geändert haben.
• Schemas sind JSON Schema 2020-12: die Input-Wurzel bleibt ein Objekt; Komposition und Refs sind erlaubt; lösen Sie externe $ref nicht automatisch auf. Output-Schemas sind nicht mehr nur object.
• Roots / Sampling / Logging sind deprecated: die Methoden funktionieren im Ein-Jahres-Fenster weiter. Neue Server sollen Sampling nicht implementieren, um den Host um eine Completion zu bitten.
• Extensions: Tasks und MCP Apps sind offizielle Extensions, keine Kern-Pflicht. Lange Arbeit nutzt ein Task-Handle + tasks/get. Erfinden Sie keine eigene Session.

Hosts und Servers, die noch auf 2025-11-25 laufen, nutzen weiter initialize. Bei gemischten Versionen gilt die ausgehandelte protocolVersion. Schicken Sie die sitzungslosen Frames dieses Artikels nicht an einen alten Server. Was Sie installieren, steht im MCP-Server-Ranking 2026.

Was Sie jetzt tun sollten

1. Zeichnen Sie drei Schichten, bevor Sie Code schreiben: das Tool Calling der Modell-API, die Host-Orchestrierung, den MCP Server. Skripte können bei den ersten zwei bleiben. Cross-IDE-Wiederverwendung ist der Moment, einen Server zu schreiben.
2. Nutzen Sie ein offizielles SDK; schreiben Sie JSON-RPC-Frames nicht von Hand: @modelcontextprotocol/sdk und die anderen offiziellen Sprachpakete erledigen bereits Entdeckung, Transport und Fehlercodes. Selbstgeschriebenes SSE oder private Felder sind der typische „Sie müssen Code ändern“-Fall im Migrationsleitfaden.
3. Schreiben Sie inputSchema als Vertrag, den Sie allein validieren können: additionalProperties: false, required, Enums, Längenobergrenzen. Modelle lassen Felder weg und schreiben Zahlen als Strings. Blocken Sie einmal mit demselben Schema vor der Ausführung.
4. stdio lokal, Streamable HTTP remote: Persönliches Debuggen braucht kein HTTP. Geteilter Teamzugriff, viele Clients oder ein Gateway ist der Moment für Remote — plus OAuth und Least Privilege.
5. Listen cachen, Ergebnisse kürzen: respektieren Sie ttlMs. Schicken Sie keine rohen Stacks zurück ins Modell. Ein größeres Fenster macht schmutziges JSON nicht sicher — siehe 1M-Token-Kontextfenster.
6. Prüfen Sie Fixtures im Browser, bevor Sie einen Live-Server anfassen: inputSchema, gute / schlechte Arguments und Beispiel-Server-Rückgaben als JSON speichern; auf dieser Seite validieren und per Diff vergleichen. Nichts wird hochgeladen. Dieselbe Gewohnheit wie beim Testen eines REST-Vertrags.

FAQ

Fazit

MCP ist die Tool-Buchse der KI-Agenten 2026: JSON-RPC 2.0 bewegt Entdeckung und Aufruf zwischen Host und Server; auf der Modellseite bleibt Tool Calling; JSON Schema ist der gemeinsame Vertrag. Es ist kein Modell, kein Framework und kein Ersatz für OpenAPI. Spezifikation 2026-07-28 hat Sessions aus dem Protokoll genommen, Anfragen müssen in sich geschlossen sein. Die drei Primitive — Tools, Resources, Prompts — haben sich nicht geändert.

Dieser Leitfaden klärt nur die Schichten. Die Nachrichtenform je Hop steht im Datenfluss-Artikel; ob ein alter Server Code ändern muss, im Migrationsartikel; welche Server Sie installieren, im Ranking-Artikel. Bevor Sie etwas live verdrahten, validieren Sie Schema und Beispiel-JSON lokal — Modelle können Sie tauschen; Feldnamen und required sollten sich nicht bewegen.