MCP — Model Context Protocol erklärt: Warum es 2026 alles ändert

MCP ist das HTTP-Moment für LLMs — und die meisten haben's nicht gemerkt. Während OpenAI, Anthropic und Google bis Mitte 2025 jeweils eigene Tool-Calling-Formate definierten und Entwickler dieselbe Integration drei Mal bauen mussten, hat Anthropic im November 2024 still und leise das Model Context Protocol veröffentlicht. Zwölf Monate später ist daraus ein De-facto-Standard geworden, mit Server-Implementierungen bei Microsoft, Block, GitHub, JetBrains und mehreren hundert kleineren Anbietern. Wer 2026 LLM-Integrationen baut und MCP ignoriert, baut für die Vergangenheit.

1. Was MCP eigentlich löst

Bis Ende 2024 hatte jede LLM-API ihr eigenes Tool-Calling-Format. OpenAI nannte es "Functions", später "Tools". Anthropic hatte ein leicht abweichendes Schema. Google Vertex hatte wieder ein eigenes. Wer eine Confluence-Integration für ein internes RAG-System bauen wollte, baute sie drei Mal — oder schrieb eine Adapter-Schicht, die selber ein kleines Projekt war.

Das eigentliche Problem war aber nicht das JSON-Schema. Es war die Architektur: Tool-Definitionen lebten im Application-Code, nicht in einem standardisierten Service. Wer ein neues Tool hinzufügen wollte, musste Application-Code anfassen, neu deployen und die Tool-Definitionen in den System-Prompt einbetten. Skalierung auf 50+ Tools wurde zur Maintenance-Hölle.

MCP löst beides. Es definiert ein einheitliches JSON-RPC-Protokoll für Tool-Discovery, Tool-Aufruf, Resource-Listing und Prompt-Templates. Und es trennt Server (die das Tooling bereitstellen) von Clients (die das LLM steuern). Dieselbe Trennung, die LSP für Code-Editoren etabliert hat — und das ist kein Zufall, die MCP-Spezifikation zitiert LSP als Vorbild.

2. Architektur: Server, Client, Transport

Drei Komponenten, mehr nicht:

• MCP-Server. Ein Prozess, der Tools, Resources oder Prompts exponiert. Geschrieben in beliebiger Sprache (offizielle SDKs: TypeScript, Python, Java, Kotlin, C#, Rust, Swift). Antwortet auf JSON-RPC-Calls wie tools/list, tools/call, resources/list.
• MCP-Client. Eingebettet im LLM-Host (Claude Desktop, Cursor, Claude Code, ChatGPT Desktop seit März 2026). Verbindet sich zu einem oder mehreren Servern, übersetzt Tool-Discovery in den Tool-Schema-Block des LLM-Calls.
• Transport. Drei Optionen: stdio (lokaler Prozess, am häufigsten), HTTP+SSE (Remote-Server), Streamable HTTP (seit Spec-Version 2025-03-26 der empfohlene Remote-Transport).

Konkretes Beispiel: ihr habt einen Postgres-MCP-Server lokal laufen. Claude Desktop verbindet sich beim Start via stdio. Wenn ihr fragt "zeig mir die letzten 10 Bestellungen aus dem Süden", listet der Client intern alle verfügbaren Tools (query_database, list_tables, describe_table), schickt sie als Tool-Definitions an Claude, Claude ruft query_database mit einem SQL-Statement auf, der Server führt aus und gibt das Resultat zurück. Drei Roundtrips, kein Custom-Code in eurer App.

3. Wer es 2026 unterstützt

Die Adoption ist 2025/2026 schneller gelaufen als bei den meisten vergleichbaren Protokollen. Stand Mai 2026:

• Anthropic-eigene MCP-Server-Registry zählt über 800 Server — von GitHub, Slack, Notion, Linear, Sentry, Stripe bis hin zu Nischen-Tools für SAP-Integration, Salesforce und Atlassian.
• OpenAI hat im März 2026 native MCP-Unterstützung in ChatGPT Desktop und der Assistants API ausgerollt — bemerkenswert, weil OpenAI vorher zwei Jahre auf eigenes Tool-Calling gesetzt hatte.
• Cursor, Windsurf, Continue, Zed, Sourcegraph Cody als IDE-Clients.
• Claude Code (CLI von Anthropic) erlaubt MCP-Server als konfigurierbare Tool-Quelle — das ist der wichtigste Hebel für Entwicklerteams, weil ihr eure eigenen internen Tools mit einem Config-Eintrag verfügbar macht.

Wichtig: MCP ist explizit nicht-proprietär. Die Spezifikation lebt bei modelcontextprotocol.io, ist Apache-2.0-lizenziert, und es gibt einen "Specification Steering Committee", in dem mittlerweile auch OpenAI und Google sitzen.

4. Wann ihr einen eigenen MCP-Server schreiben solltet

Drei klare Trigger:

• Ihr habt ein internes System (CRM, ERP, Wiki, Ticketing), das ihr LLM-zugänglich machen wollt. Statt eine Vendor-spezifische Integration zu bauen, schreibt ihr einen MCP-Server. Eine Junior-Entwickler-Person schafft das in 1–2 Tagen für ein Standard-CRUD-System. Der gleiche Server funktioniert dann mit Claude, ChatGPT, Cursor und allem, was 2027 noch kommt.
• Ihr braucht reproduzierbare Tool-Sets pro Team oder Customer. MCP-Server lassen sich pro Workspace konfigurieren — das macht Multi-Tenant-Setups deutlich sauberer als Tool-Definitionen im Code.
• Ihr seid ein Tool-Hersteller und wollt LLM-Reichweite. Wer 2026 ein SaaS-Produkt baut und keinen MCP-Server anbietet, wird in den nächsten 18 Monaten Marktanteil verlieren — vor allem in Developer-Tools-Märkten.

5. Trade-offs: wo MCP weh tut

Damit das hier nicht zu enthusiastisch klingt — drei reale Schwachstellen:

• Performance-Overhead bei stdio-Servern: ein zusätzlicher Prozess pro Server-Verbindung, ein zusätzlicher JSON-RPC-Roundtrip pro Tool-Call. Für 95 % der Use-Cases vernachlässigbar (Latenz +50 bis +150 ms), für hochfrequente Realtime-Integrationen relevant.
• Authentifizierung ist Stand 2026 noch unscharf. Die Spezifikation empfiehlt OAuth 2.1 für Remote-Server, aber viele Server-Implementierungen lösen Auth über Environment-Variablen oder Config-Files. Wer Enterprise-Setups baut, muss hier eigene Lösungen draufsetzen.
• Tool-Sprawl wird ein echtes Problem. Wenn ihr 15 MCP-Server einbindet, hat das LLM plötzlich 80+ Tools zur Auswahl — und das senkt die Tool-Call-Accuracy messbar. Best Practice: Server-Gruppen pro Use-Case-Kontext, nicht "alles immer verfügbar".

6. Sicherheit: was ihr bedenken müsst

MCP-Server bekommen Zugriff auf eure Tools — und damit potenziell auf Daten, Filesystem und Netzwerk. Drei Anti-Patterns, die wir 2025/2026 in Audits gesehen haben:

• MCP-Server mit Wildcard-Filesystem-Zugriff (z.B. der offizielle Filesystem-Server ohne Pfad-Restriktion) in Prod-Setups. Resultat: jeder Tool-Call kann theoretisch /etc/passwd lesen.
• MCP-Server, die Secrets in Environment-Variablen erwarten und beim ersten Call ohne weitere Prüfung an LLM-Antworten weiterreichen. Klassisches Prompt-Injection-Risiko.
• Remote-Server ohne TLS oder mit Self-Signed-Cert. Hat sich überraschend häufig in internen POCs eingeschlichen.

Mitigations: Path-Allowlists pro Server, Secret-Manager statt Env-Vars bei Production-Setups, signierte Server-Manifeste (Spec-Erweiterung seit März 2026). Für Hochrisiko-Use-Cases im Sinne des EU AI Act ist eine zusätzliche Audit-Logging-Schicht zwingend.

7. Konkretes Migrations-Beispiel

Wir haben Anfang 2026 bei einem Wiener Logistik-Kunden eine bestehende OpenAI-Function-Calling-Integration auf MCP umgebaut. Ausgangslage: 12 interne Tools (SAP-Reads, Sendungsverfolgung, Mandanten-Lookup), in der App-Codebase als OpenAI-Functions hartcodiert. Pain: jedes neue Tool brauchte Code-Change und Deployment.

Migration in 3 Wochen:

1. Woche 1: MCP-Server in TypeScript geschrieben, die 12 Tools 1:1 übernommen, lokal getestet mit Claude Desktop.
2. Woche 2: Server als Docker-Image deployed, HTTP-Transport mit OAuth 2.1, Integration in die bestehende ChatGPT-Enterprise-Umgebung sowie parallel in Claude Code für die Dev-Teams.
3. Woche 3: App-Code aufgeräumt (~600 Zeilen Function-Schema-Boilerplate gelöscht), Monitoring auf den MCP-Server umgestellt, Doku geschrieben.

Resultat: dieselbe Funktionalität, Dev-Teams können neue Tools jetzt hinzufügen, ohne die Hauptanwendung anzufassen, und dieselbe Integration läuft mit drei verschiedenen LLM-Clients.

Was als Nächstes?

Wer 2026 LLM-Integrationen baut, sollte MCP als Default annehmen — und proprietäre Tool-Calling-Schnittstellen nur dann nutzen, wenn ein konkreter Performance- oder Feature-Grund dagegen spricht. Konkrete Schritte für die nächsten 30 Tage: spielt einen Standard-MCP-Server lokal durch (@modelcontextprotocol/server-filesystem ist der schnellste Einstieg), prüft, welche eurer internen Tools sich als MCP-Server lohnen, und plant die Migration mindestens einer bestehenden Integration. Wenn ihr dabei Sparring oder eine zweite Meinung braucht — ein 30-Minuten- Discovery-Call kostet euch nichts und klärt meist die wichtigsten Architektur-Fragen.