MCP ohne KI-Brille: Was das Protokoll wirklich ist

Wer sich mit MCP beschäftigt, stolpert überall über dieselben Begriffe: LLM-Tools, Claude-Integration, KI-Agenten. Man könnte meinen, MCP sei eine Art KI-Magie. Das Gegenteil ist der Fall. MCP ist ein Protokoll – nicht mehr, nicht weniger. Und ein ziemlich simples dazu.

Die Verwirrung

MCP steht für Model Context Protocol. Der Name trägt zur Verwirrung bei. “Model” klingt nach Machine Learning, “Context” nach etwas Kompliziertem. In Wahrheit beschreibt MCP lediglich, wie ein Client Fähigkeiten abfragen und nutzen kann.

Die Verwirrung entsteht, weil MCP aus der LLM-Welt stammt. Anthropic hat es entwickelt, damit Claude lokale Tools aufrufen kann. Das bedeutet aber nicht, dass MCP an LLMs gebunden wäre. Der Client kann alles sein – ein Chatbot, ein Skript, eine Desktop-App, ein Cron-Job.

Was MCP technisch ist

MCP besteht aus drei Teilen:

Discovery: Der Server beschreibt seine Fähigkeiten. Jedes Tool hat einen Namen, eine Beschreibung und ein JSON-Schema für die Eingabe. Der Client liest diese Metadaten und weiß dann, welche Funktionen verfügbar sind.

Call: Der Client ruft ein Tool auf. Er schickt den Tool-Namen und die Argumente als JSON. Der Server führt die Aktion aus und antwortet.

Result: Die Antwort kommt strukturiert zurück – als Text, JSON oder in einem anderen definierten Format. Der Client verarbeitet sie weiter.

Das ist der gesamte Mechanismus. Kein Geheimnis, keine Magie. JSON rein, JSON raus, mit einem Schema dazwischen.

Warum es sich wie RPC anfühlt

Wer mit SOAP, JSON-RPC oder gRPC gearbeitet hat, erkennt das Muster sofort. MCP ist im Kern ein Remote Procedure Call mit Discovery. Genauer: MCP baut direkt auf JSON-RPC 2.0 auf – einem Standard von 2010. Das "jsonrpc": "2.0" im Request ist keine MCP-Erfindung, sondern die offizielle Versionskennung des JSON-RPC-Protokolls.

Was von JSON-RPC kommt: Nachrichtenformat, Request-IDs, die method/params/result-Struktur. Was MCP darauf definiert: Die konkreten Methoden (initialize, tools/list, tools/call) und die Schemas für Tools. JSON-RPC ist der Umschlag, MCP ist der Brief.

Der Unterschied zu klassischem RPC: Die Tool-Auswahl ist nicht fest verdrahtet. Der Client entscheidet zur Laufzeit, welches Tool er benötigt. Bei klassischem RPC weiß der Client vorab, welche Methode er aufruft. Bei MCP fragt er zunächst: “Was kannst du?” und entscheidet dann. Das ist der wesentliche konzeptionelle Unterschied – und selbst der ist optional. Nichts hindert einen Client daran, immer dasselbe Tool aufzurufen.

Die Einordnung: REST ist ressourcenorientiert (GET /users/123), RPC ist methodenorientiert (getUser(123)), MCP ist fähigkeitsorientiert (Tool “get_user” mit Schema). Alles valide Ansätze mit unterschiedlichen Schwerpunkten.

Der Inspector als Beweis

Dass MCP ohne LLM funktioniert, lässt sich leicht demonstrieren: Der MCP Inspector ist ein Debug-Tool von Anthropic – eine Web-Oberfläche, die MCP-Server anspricht. Kein LLM involviert. Der Inspector macht genau das, was jeder Client macht: Discovery abfragen, Tools auflisten, Calls absetzen, Ergebnisse anzeigen.

Der Inspector demonstriert: MCP ist ein Protokoll. Wer JSON parsen kann, kann MCP sprechen. Der Quellcode liegt auf GitHub – ein Blick hinein zeigt JSON-Parsing und UI-Code, mehr nicht.

Transport: stdio ist Fork und Pipes

Die MCP-Dokumentation nennt zwei Transporte: stdio und HTTP. Das klingt nach einer Einschränkung, ist aber keine. MCP ist transportagnostisch – die beiden sind lediglich Referenzimplementierungen.

stdio funktioniert so: Der Client startet den Server als Kindprozess (fork/exec). Die Kommunikation läuft über stdin und stdout – JSON-Nachrichten, zeilenweise getrennt. Das ist Unix-Grundwissen aus den 70ern, keine neue Erfindung.

HTTP funktioniert wie jeder andere Webservice: POST-Requests mit JSON-Body, JSON-Responses.

Theoretisch lässt sich MCP auch über Shared Memory, Message Queues, WebSockets oder Brieftauben (RFC 1149) betreiben. Das Protokoll ist unabhängig vom Transport, solange die Nachrichten ankommen. Die Beschränkung auf stdio und HTTP ist pragmatisch gewählt, nicht technisch bedingt.

Was MCP nicht ist

MCP ist kein Workflow-System. Es kennt keine Abfolgen, keine Bedingungen, keine Schleifen. Ein Aufruf, ein Ergebnis.

MCP ist kein Session-Management. Es gibt keinen Zustand zwischen Aufrufen. Wenn der Client Kontext benötigt, muss er ihn selbst mitschicken.

MCP ist keine Orchestrierung. Wenn mehrere Tools zusammenarbeiten sollen, muss eine Komponente außerhalb von MCP die Koordination übernehmen.

MCP ist bewusst minimal gehalten. Es regelt nur: Was kannst du, wie rufe ich es auf, was kommt zurück. Alles andere ist Sache des Clients oder der umgebenden Architektur.

Die eigentliche Stärke

MCP ist nicht revolutionär. Die Technik dahinter existiert seit Jahrzehnten. Was MCP liefert, ist Standardisierung. Statt dass jeder sein eigenes Tool-Protokoll erfindet, gibt es ein gemeinsames Schema.

Das ermöglicht etwas Interessantes: App A kann einen Auftragnehmer für eine Aufgabe suchen, App Z kann sich als Auftragnehmer anbieten. Beide sprechen dasselbe Protokoll. Keine REST-Endpunkte aushandeln, keine API-Dokumentation wälzen, keine Versionskonflikte. Discovery, Call, Result.

Ob der Client dabei ein LLM ist oder ein Shell-Skript, spielt keine Rolle. Das Protokoll funktioniert in beide Richtungen gleich.

Ein Beispiel: Echo-Server in 50 Zeilen

Theorie ist gut, Code ist besser. Ein minimaler MCP-Server, der zwei Tools anbietet:

# server.py - Die Tool-Definitionen (Discovery)
TOOLS = {
    "hello_world": {
        "name": "hello_world",
        "description": "Gibt eine freundliche Begrüßung zurück",
        "inputSchema": {"type": "object", "properties": {}}
    },
    "echo": {
        "name": "echo",
        "description": "Gibt den übergebenen Text zurück",
        "inputSchema": {
            "type": "object",
            "properties": {
                "text": {"type": "string", "description": "Der Text"}
            },
            "required": ["text"]
        }
    }
}

Der Server liest JSON von stdin, verarbeitet es, schreibt JSON auf stdout. Der Client bekommt die Streams injiziert, der Bootstrapper (cli_run.py) verbindet beide über Fork und Pipes.

Die Ausgabe:

=== Discovery ===
Verfügbare Tools: 3
  - hello_world: Gibt eine freundliche Begrüßung zurück
  - echo: Gibt den übergebenen Text zurück
  - calculate: Führt eine Berechnung durch

=== Tool Call: echo ===
→ {"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "echo", "arguments": {"text": "MCP ist nur JSON über Pipes!"}}}
← MCP ist nur JSON über Pipes!

Neben der CLI-Version (cli_run.py) gibt es auch einen Mini-Inspector mit Tkinter-GUI (gui_run.py) – gleicher Server, gleiche Pipes, grafische Oberfläche. Lazy Connect, Discovery-basierte Buttons, Schema-aware Eingabedialoge. Weil MCP egal ist, wer fragt.

Der vollständige Code liegt auf GitHub: cuber-it/mcp_echo_demo. Das ist ein Living Project – Details und aktuelle Änderungen in der README.

Unterm Strich

MCP ist ein Protokoll. JSON-basiert, schema-first, mit eingebauter Discovery. Es stammt aus der LLM-Welt, ist aber nicht auf LLMs beschränkt. Unter der Haube ist es RPC mit ein paar Konventionen.

Wer MCP verstehen will, muss keine KI verstehen. Es reicht zu wissen, wie JSON aussieht und was ein Funktionsaufruf ist. Der Rest ist Dokumentation.

Disclaimer: Der Code ist ein Proof of Concept. Wer einen MCP-Server mit Shell-Zugriff betreibt, sollte wissen, was er tut.

GitHub: cuber-it/mcp_echo_demo

Aktualisiert: 2025-01-13

Teil der Serie MCP-Experimente · Nächster Teil: MCP-Server mit Python