Wenn du in den letzten Monaten Indie-Builder-Twitter, Hacker News oder r/LocalLLaMA gelesen hast, ist dir MCP überall begegnet. Anthropic hat das Protocol Ende 2024 released, OpenAI hat es 2025 adoptiert, und seit Anfang 2026 ist es de-facto-Standard für Tool-Integration in Coding-Agents. Hier knapp was es ist und warum es relevant ist.
In einem Satz
MCP ist Anthropics offener Standard, mit dem LLM-Hosts und externe Tool-Server über ein gemeinsames JSON-RPC-Protokoll Capabilities aushandeln und Tool-Calls ausführen.
In drei Absätzen
Konzeptionell ist MCP ein USB-C für KI-Tools. Vorher musste jeder Host (Claude Desktop, Cursor, Continue, Aider, etc.) jedes Tool individuell integrieren, mit eigenem Protokoll, eigenen Authentifizierungs-Pattern, eigenem Discovery-Mechanismus. MCP ersetzt das durch eine einzige Spezifikation. Ein MCP-Server beschreibt seine Tools, Resources und Prompts in standardisierter Form, ein MCP-Client kann jeden konformen Server nutzen, ohne dass jemand pro Kombination Glue-Code schreiben muss.
Mechanisch läuft MCP über JSON-RPC 2.0 als Transport, mit drei Hauptprimitiven: Tools sind aufrufbare Funktionen mit JSON-Schema-Argumenten, Resources sind lesbare Daten-Snapshots (Dateien, DB-Rows, API-Responses), und Prompts sind vordefinierte Prompt-Templates die ein Server für häufige Workflows bereitstellt. Der Host startet einen Sub-Prozess für jeden konfigurierten Server (oder verbindet über HTTP/SSE), das Protokoll handhabt Capability-Discovery, Tool-Listing und das Aufrufen.
Relevant wird MCP wenn du als Builder mehr als einen LLM-Host nutzt oder mehr als ein Tool integrieren willst. Sobald du Filesystem-Access, eine Datenbank, eine Such-API und ein Calculator-Tool an Claude UND Cursor UND ChatGPT-Desktop angebunden hast, sparst du mit MCP genau einmal Integrations-Aufwand statt dreimal. Die Trade-offs sind: Initial-Setup-Overhead pro Server, Performance-Cost durch JSON-RPC-Roundtrips, und Security-Surface (jeder Server läuft mit den Permissions des Hosts).
Tief, wenn du willst
Das Protokoll selber ist auf github.com/anthropic/mcp dokumentiert. Die Spezifikation ist überraschend kurz, etwa 80 Seiten, und basiert auf JSON-RPC 2.0 mit drei Lifecycle-Phasen: Initialize (Capability-Handshake), normaler Betrieb (Tool-Calls, Resource-Reads, Prompts), und Shutdown.
Capability-Negotiation ist der erste Roundtrip nach Connection-Open. Client und Server tauschen aus was sie können (welche MCP-Version, welche optionalen Features wie Logging oder Progress-Notifications, ob Resources subscribable sind), das ist Vorbedingung für alles weitere. Wer schon mal LSP (Language Server Protocol) gesehen hat, kennt das Pattern, MCP ist konzeptionell stark von LSP inspiriert.
Tools sind das interessanteste Primitiv. Ein Server deklariert seine Tools mit name, description, und einem JSON-Schema für die Argumente. Der Client kann diese listen (tools/list) und einzelne aufrufen (tools/call). Das Modell sieht die Tool-Liste typisch als Teil seines System-Prompts und entscheidet eigenständig wann ein Tool-Call sinnvoll ist. Wichtig: das Modell und der Host sind getrennt, das Modell macht den Tool-Selection-Vorschlag, der Host entscheidet ob er den Call ausführt (und kann z.B. Genehmigung vom User einholen).
Security-Modell ist Capability-Based mit Host-Verantwortung. Jeder Server läuft als Sub-Prozess des Hosts und hat technisch dieselben Permissions wie der Host. Es gibt keine Sandboxing-Garantie im Protokoll selber, das ist Host-Job. Anthropic hat im Mai 2026 mit “MCP-Sandboxes” einen optional spec-Anhang vorgeschlagen, der wenn implementiert eine WebAssembly-Sandbox-Schicht zwischen Host und Server einzieht. Stand jetzt ist das noch nicht weit verbreitet.
Transport-Optionen sind stdio (klassisch, lokaler Sub-Prozess) und HTTP+SSE (Server-Sent Events für Streaming). Lokale Setups nutzen stdio, Remote-Setups HTTP. Der Trend Mitte 2026 geht klar zu HTTP, weil dann ein Server-Anbieter (z.B. ein SaaS) seine eigenen MCP-Server hosten kann und Tausende Hosts gleichzeitig bedienen.
Trade-offs in Produktion: Wenn du MCP einsetzst, mehrere praktische Hinweise. Erstens, Tool-Selection-Quality variiert stark zwischen Modellen. Claude und GPT-5 wählen meist sinnvoll, kleinere lokale Modelle (Llama-70B, Qwen) brauchen oft explizite Hints im System-Prompt. Zweitens, Resource-Performance ist limitiert: jeder Read ist ein Roundtrip, also caching-pattern im Server-Layer einbauen. Drittens, Discovery (tools/list) wird oft vom Host aggressiv gecacht, das heisst neue Tools werden manchmal erst nach Host-Restart sichtbar.
Wenn du selber einen MCP-Server bauen willst, gibt es Reference-Implementations in Python (mcp Package) und TypeScript (@modelcontextprotocol/sdk). Hello-World ist etwa 30 Zeilen Code. Simon Willisons First-Impressions-Post ist ein guter Einstieg mit konkretem Code.
Wo dir das diese Woche begegnet ist
In der Aggregation der letzten Woche sind mindestens vier MCP-relevante Items: Cursor 1.0 hat MCP-First-Class-Support announced, Aider hat seine --mcp-server Flag dokumentiert, ein Reddit-Thread auf r/AI_Agents diskutiert Multi-Server-Setups, und Anthropic hat einen neuen Spec-Patch released der Resource-Subscription-Patterns klärt. Plus wurde MCP im Cisco-OpenAI-Codex-Rollout als Standardisierungs-Layer für Enterprise-Tools genannt, Diskussion dazu auf Hacker News.
Wenn du noch keinen MCP-Server gebaut hast: nimm dir 30 Minuten und schreib einen Filesystem-MCP-Server der dein wichtigstes Notes-Verzeichnis exposed. Du wirst schnell merken, ob die Investition für deinen Workflow lohnt.
Erklärt 2026-05-28 durch kaschnai-Konzept-Pipeline. Quality-Gates: 3-Tier-Klarheit (Gate 12), Source-Diversity (5 Quellen). Nächste Frische-Prüfung: 2027-05-28.