September 2026

Tutorial

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

Cursor, Claude Desktop und selbst gebaute Agenten sagen alle MCP. Das Protokoll chattet nicht und denkt nicht. Es legt fest, wie eine Werkzeugliste entdeckt wird, wie das JSON eines Aufrufs über JSON-RPC fährt und wie das Ergebnis in den Modellkontext zurückschreibt.

2026 zeigt fast jeder Editor mit Agent MCP auf der Einstellungsseite. Die einen sehen den nächsten Plugin-Store, andere ein Pflichtprotokoll, wieder andere vermengen es mit Tool Calling, Function Calling und A2A. Dieser Text zieht eine Ingenieurdefinition zu: Model Context Protocol (MCP) ist ein offenes Protokoll, mit dem ein KI-Client Werkzeuge, Ressourcen und Prompts auf einem Server entdeckt und in den Modellkontext hängt. Der Transportumschlag ist JSON-RPC 2.0; die Fachmethoden heißen tools/list, tools/call und Verwandte. Es ersetzt das Modell nicht und ist kein Agent — der Agent ist eine Schleife; MCP ist die Schicht in der Schleife, die sagt, wie ferne Werkzeuge gesehen und aufgerufen werden. Am Ende trennen Sie vier Dinge: Protokoll, Umschlag, Runtime, Werkzeugwahl des Modells. Auf der Site gibt es bereits Schema-Mapping, zustandsloses Remote-MCP, A2A-Schichtung und eine Agent-Definition. Hier ist die Tür, nicht jene Tauchgänge.

Was MCP ist: kein Modell — ein Protokoll für Werkzeuge

Die Minimaldefinition braucht drei Parteien: einen Host (Editor oder Agent-Prozess), einen Client (die Seite im Host, die mit Servern spricht), einen Server (Prozess oder HTTPS-Endpunkt mit Werkzeugen, Ressourcen, Prompts). Der Client holt den Katalog, injiziert name, description und inputSchema in den Kontext und sendet nach der Modellentscheidung tools/call. MCP regiert Entdeckung und Aufrufform. Nicht, wie das Modell denkt.

„KI-Plugin“ trifft nur halb. Ein Browser-Plugin hängt an einem Wirt; ein MCP-Server kann von vielen Clients wiederverwendet werden — dieselbe Rechnungssuche bedient Cursor, Claude Desktop oder Ihren Orchestrator. Der Unterschied ist nicht „können wir eine Funktion rufen“, sondern ob Katalog und Aufrufumschlag standardisiert sind. Ein selbst gebauter OpenAPI-Adapter ruft schon HTTP; ein zweiter Client heißt den Adapter neu schreiben. MCP faltet diese Schicht ins Protokoll. Offizielle Begriffe und Spezifikation:Model-Context-Protocol-Dokumentation.

Auf der Zeitlinie: Anthropic hat MCP 2024 quelloffen gemacht; Ende 2025 lag das Protokoll unter der Agentic AI Foundation (AAIF) der Linux Foundation. 2026 behandeln Hosts es als Standardkanal für ferne Werkzeuge, nicht als Demo. Eine Protokollversion steht in _meta — 2026-07-28 heißt „beide Seiten teilen diese Semantik“, nicht „das Modell wurde klüger“. Der Abstand zu Chatbot oder Cron-Workflow steht inWas ist ein AI Agent: ohne Schleife und ohne prüfbare Argumentform ist es nur Chat; eine Schleife über lokale Funktionen kann trotzdem ein Agent sein — nur ohne standardisierten Fernkatalog.

JSON-RPC 2.0: warum dieser Umschlag

MCP hat kein neues RPC erfunden. Jede Protokollaktion sitzt in einem JSON-RPC-2.0-Umschlag: jsonrpc, id, method, params oder error. Anfrage und Antwort teilen eine id; Benachrichtigungen dürfen sie weglassen. Für Gateways und Logs ist das leichter zu zerlegen als ein eigener Stream-Frame: zuerst method, dann Fach. Felder stehen in derJSON-RPC-2.0-Spezifikation.

method ist ein Protokollverb, nicht Ihr Fachfunktionsname. tools/list listet, tools/call ruft, resources/read liest. Der Fachname lebt in params.name, Argumente in params.arguments. searchInvoices als method zu schreiben ist ein häufiger Fehlschluss — das ist Ihr JSON-RPC-Dienst, nicht MCP. Eine Standard-Kataloganfrage sieht so aus:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Der Umschlag löst drei Dinge: Multiplex (mehrere ids unterwegs), klassifizierbare Fehler (Parse, unbekannte Methode, Fachablehnung) und tauschbaren Transport (stdio-Kindprozess oder Streamable HTTP tragen dasselbe JSON). Er entscheidet nicht, ob arguments stimmen. Ein legaler JSON-RPC-Umschlag kann ein arguments-Objekt mit fehlenden Feldern an den Server geben. Der Server muss selbst parsen und gegen inputSchema prüfen.

Wie ein KI-Agent MCP nutzt: entdecken → wählen → aufrufen

Das Demovideo abziehen: eine MCP-verdrahtete Agentenschleife hat weiter fünf Schritte. Neu ist, dass Schritt 2 und 4 nicht mehr an lokale Funktionen kleben:

  1. Das Nutzerziel kommt in den Kontext (natürliche Sprache plus optionale Systemgrenzen).
  2. Der Client sendet tools/list an jeden verbundenen MCP-Server und macht aus dem Katalog tools / functions, die das Modell lesen kann.
  3. Das Modell liefert tool_calls (Funktion + arguments) oder finalen Text / Structured Output.
  4. Die Runtime parst arguments, sendet MCP tools/call und schreibt das result in die Nachrichten.
  5. Das Modell liest das Ergebnis und wählt das nächste Werkzeug oder stoppt. maxSteps, Abbruch oder Schema-Fehler stoppen ebenfalls.

Die MCP-Anfrage in Schritt 4 sieht so aus. params.arguments ist bereits ein Objekt, kein String. Eine Protokollversion kann an _meta hängen, damit zustandsloses Routing etwas zu lesen hat:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

Ein Agent hängt nicht an MCP. Lokale Funktionen, OpenAPI und eigenes HTTP gelten als Werkzeuge. Der Wert von MCP: ein Server, den viele Hosts entdecken, mit gleichem Katalog und gleicher Aufrufform remote. Das Kriterium ist „wird ein zweiter Client diesen Werkzeugsatz wiederverwenden“, nicht „sieht es nach 2026 aus“. Die Ingenieurdefinition der Schleife steht inwie ein AI Agent arbeitet.

Modell-Tool-Calling: tool_calls vs tools/call

Ingenieurtechnisch sind Tool Calling und Function Calling ein Mechanismus: Das Modell fasst die Datenbank nicht an; es sendet eine strukturierte Bitte „rufe diese Funktion mit diesen Argumenten“. MCP ist der nächste Hop: Die Runtime übersetzt in JSON-RPC tools/call. Feldnamen der beiden Hops werden ständig vermischt:

Dieser Hop Wer sendet Wie arguments aussehen
Modell-Tool-Calling Modell-APIs von OpenAI / Anthropic / Gemini (u. a.) Meist ein JSON-String in tool_calls oder tool_use
MCP tools/call Der MCP-Client im Host params.arguments ist ein JSON-Objekt
Downstream-Fach-API Der MCP-Server oder Ihr Adapter HTTP-JSON-Body / SQL-Parameter — gleiches Schema-Ursprung
Finaler Structured Output Letzter Hop des Modells Antwort an Nutzer oder Downstream — keine Werkzeugeingaben

Wenn das Modell aufruft, sieht ein typisches tool_calls so aus. arguments ist weiter ein String. Die Runtime parst zuerst und legt das Objekt in MCP params.arguments. Den String roh in JSON-RPC zu stopfen macht daraus „ein Stringfeld namens arguments“ — die Schema-Prüfung des Servers fällt sofort durch.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

Vendor-Hüllen unterscheiden sich: OpenAI tools[].function.parameters, Anthropic input_schema, Gemini function_declarations. MCP nutzt Tool.inputSchema. Namen differieren; das kanonische Schema sollte eine Datei sein. Feldabgleich und warum strict jede property in required verlangt, steht inMCP und JSON Schema. Die Endantwort läuft über Structured Output — teilen Sie diese Datei nicht mit Werkzeugeingaben.

Karte 2026: lokal, remote, zustandslos, A2A

Zwei Haupttransporte. Lokales stdio: Der Host startet einen Kindprozess, JSON-RPC fährt über stdin/stdout — gut für lokales Dateisystem oder lokale DB. Remote Streamable HTTP: Der Client POSTet denselben Umschlag an einen HTTPS-Endpunkt — gut für geteilte Rechnungen, Tickets, interne APIs. Remote heißt nicht mehr „Handshake, dann Session-ID“. Um 2026-07-28 sollen Anfragen selbstbeschreibend sein, damit ein Gateway nach method limitieren kann.

Zustandslos meint die Protokollschicht: jede Instanz nimmt jede Anfrage. Die Anwendung hat weiter Datenbank, Idempotenzschlüssel und Identität. „Protokoll zustandslos“ als „Werkzeuge brauchen keine Prüfung“ zu lesen, ist verkehrt — ohne Session-Cache dürfen Sie nicht annehmen, dass das tools/list der letzten Runde noch gilt. Ein veralteter Katalog schreibt die falsche Form in tools/call. Details:zustandsloses MCP und JSON-RPC.

MCP ist auch kein Multi-Agent-Protokoll. Ein Planer, der an Preis-, Compliance- und Logistik-Agenten übergibt, nutzt A2A message/send, nicht tools/call. Jeder Spezialist kann intern weiter MCP für seine Datenbank nutzen. „Protokollkrieg“ ist meist der falsche Rahmen: eine Schicht zu Werkzeugen, eine zu Agenten. VergleichA2A vs MCP. Spezifikation und Implementierungen imMCP-GitHub — Versionsänderungen am Spec-Repo festmachen, nicht am Blog eines einzelnen Hosts.

Validierung vor Ort und JSONVue

Jeder Hop: parse → Schema → Fachregeln. Ein legaler MCP-Umschlag macht arguments nicht legal. Ein kluges Modell ersetzt diese drei Schritte nicht.

  1. arguments-String des Modells: JSON.parse; bei Fehler raw + tool_call-id loggen und retrybaren Umschlag zurückgeben — noch nicht downstream.
  2. Gegen inputSchema / parameters prüfen (Draft 2020-12); path und keyword ausgeben.
  3. Fachtor: Datumsbereich, Enum vs Rechte, Fremdschlüssel. Erst dann darf der Server die Downstream-API rufen.

Drei Blobs nebeneinander: Modell-arguments, params.arguments an MCP, Objekt, das der Server wirklich nutzte. Abweichung ist fast immer der Adapter. Im Browser:JSON-Formatierer fürs Parsen;JSON-Schema-Validator für arguments vs Schema-Datei;JSON Diff für Modell-arguments vs MCP-/HTTP-Body. valid / missing-field / wrong-enum in CI und manuellem Debug teilen.

Weiter: Was ist ein AI Agent, MCP und JSON Schema, Zustandsloses MCP, A2A vs MCP.

FAQ

Sind MCP und Tool Calling dasselbe?

Nein. Tool Calling / Function Calling ist der Modell-API-Hop: Das Modell wählt Funktionsname und arguments. MCP ist der nächste Runtime-Hop: Der Client entdeckt und ruft ein fernes Werkzeug per JSON-RPC. Tool Calling geht ohne MCP; ein MCP-Server geht ohne Modell. Beide Hops in ein Wort pressen, und Logs sagen nicht, welche Schicht brach.

Geht ein KI-Agent ohne MCP?

Ja. Ein Agent ist ein Modell, das in einer Schleife Aktionen wählt, während eine Runtime Werkzeuge ausführt. Lokale Funktionen, OpenAPI und eigenes HTTP reichen, wenn arguments und results prüfbar sind. Der Wert von MCP ist Katalog und Transport — besonders remote und multi-client. Keine Schicht nur, um „nach 2026 auszusehen“.

JSON-RPC ist alt — warum nutzt MCP es noch?

Weil es alt, klein und überall parsebar ist. MCP braucht eine routbare method, eine ausrichtbare id, ein stabiles error — kein neues Frame-Format. Streamable HTTP tauscht den Transport, nicht den Umschlag. JSON-RPC „nicht modern“ zu nennen, heilt selten falsche arguments.

Prüft der MCP-Server Werkzeugargumente automatisch?

Nein. inputSchema ist eine Deklaration; das Protokoll startet keinen Validator. Client und Server sollen lokal parsen + Schema. Nur dem Modell oder nur dem Gegenüber glauben, und fehlende Felder landen im Fach. Taxonomie: der KI-JSON-Fehlerleitfaden.

Fazit und nächste Schritte

MCP 2026: Werkzeuge per JSON-RPC entdecken und aufrufen, Ergebnisse in den Modellkontext zurückschreiben. Kein Modell, kein Agent, kein A2A. Tool Calling regiert die Funktionswahl; MCP regiert Finden und Fernaufruf; JSON Schema regiert die Form jedes Hops.

Als Nächstes: die drei JSON (Modell-arguments, MCP params.arguments, Downstream-Body) auflisten und ein gemeinsames Schema prüfen; valid / fehlendes Feld / falsches Enum in JSONVue replayen. Protokoll im zustandslosen MCP-Artikel; Felder im Schema-Artikel; Multi-Agent im A2A-Vergleich.