Was ist MCP (Model Context Protocol)? Standard für Tool-Use Mai 2026

Was ist MCP?

MCP steht für Model Context Protocol. Es ist ein offener Standard, der spezifiziert, wie Sprachmodelle auf Werkzeuge, Datenquellen und externe Server zugreifen. Statt dass jeder LLM-Anbieter (OpenAI, Anthropic, Google) sein eigenes proprietäres Tool-Use-Format vorgibt und jede Integration einzeln gebaut werden muss, definiert MCP eine einheitliche Sprache.

Anthropic hat MCP im November 2024 als Open-Source-Spezifikation veröffentlicht (modelcontextprotocol.io, Apache 2.0). Die Idee war einfach: Tool-Use-APIs sollten standardisiert sein wie HTTP für Web-Server. 2025 wuchs die Adoption: erste grosse Integrationen in Anthropic-Claude-Desktop, Cursor IDE, Continue, dann Cloudflare, Block, Replit. Im Verlauf 2025 und Anfang 2026 haben OpenAI, Google und Microsoft offizielle MCP-Adoption angekündigt – OpenAI mit Unterstützung in der Agents SDK (März 2025), Google mit Vertex AI / Gemini Tool-Use-Bridge (Ende 2025), Microsoft mit GitHub Copilot und Azure AI Studio (2025-2026). Mai 2026 ist MCP der breit akzeptierte Standard.

Mai 2026 existieren über 500 öffentliche MCP-Server (siehe modelcontextprotocol.io/servers und GitHub-Registries wie awesome-mcp-servers). Beispiele: Filesystem-Server (Lese-/Schreib-Zugriff auf lokale Dateien), GitHub-Server (Repos, Issues, PRs), Postgres-Server (DB-Queries mit Schema-Introspektion), Slack-Server (Channels, DMs, Suche), Google-Drive-Server, Notion-Server, Linear-Server, Kubernetes-Server, Sentry-Server, Datadog-Server. Plus tausende interne, nicht öffentliche Server in Konzern-Umgebungen.

Warum es ein Wendepunkt ist

Vor MCP war Tool-Use ein Provider-spezifisches Problem. Wer ein Werkzeug für Claude baute, musste es für GPT separat bauen – und für Gemini ein drittes Mal. Wer Anbieter wechselte, baute alle Integrationen neu. Wer mehrere Anwendungen mit den gleichen Werkzeugen ausstattete, kopierte den Integrations-Code. Drei Konsequenzen.

Erstens: Lock-in war stark. Ein Treuhand-System, das Tool-Use mit Claude implementiert hatte, konnte nicht ohne weiteres auf GPT-4 wechseln – selbst wenn GPT-4 für eine bestimmte Aufgabe besser geworden wäre. Die Integrations-Schicht musste umgeschrieben werden.

Zweitens: Innovation in der Werkzeug-Welt war langsam. Wer ein neues Tool baute (z.B. einen Bexio-Connector für LLMs), musste pro Anbieter eine eigene Adapter-Variante pflegen. Open-Source-Werkzeuge entstanden langsamer als der eigentliche Bedarf wuchs.

Drittens: Datenquellen-Anbindung war Code-aufwendig. Eine einfache Postgres-Anbindung an einen Agent verlangte 100-300 Zeilen Code pro Anbieter, mit eigener Fehlerbehandlung, Auth und Schema-Modellierung.

MCP löst alle drei. Ein MCP-Server (z.B. ein Postgres-MCP-Server) wird einmal gebaut, dann von jedem MCP-fähigen Modell und jeder MCP-fähigen Anwendung verwendet. Wechsel von Claude zu GPT? Provider-Konfiguration ändern, Werkzeuge bleiben gleich. Neues Werkzeug für das gesamte Eco-System bauen? Ein MCP-Server, der von Tag 1 in Claude, GPT, Gemini und allen MCP-Clients funktioniert.

Für ein KMU bedeutet das praktisch: Sie investieren in MCP-Server, nicht in Anbieter-spezifische Adapter. Ein MCP-Server für Ihre interne Mandanten-DB ist eine Einmal-Investition (typisch CHF 1500-6000 für KMU-Komplexität), die sofort in jedem Tool nutzbar ist – Claude Desktop, Cursor, eigene Agent-Pipelines, kuenftige Tools. Ohne MCP hätten Sie pro Tool eine eigene Integration gebraucht.

Technik im Detail

MCP definiert drei Konzepte und ein Transport-Protokoll.

Resources. Eine Datenquelle, die ein MCP-Server bereitstellt – z.B. eine bestimmte Datei, ein Mandanten-Datensatz, ein Postgres-Schema. Das Modell kann eine Liste der verfügbaren Resources abfragen und einzelne Resources auslesen. Resources sind read-only.

Tools. Eine Funktion, die das Modell aufrufen kann – z.B. "search_documents(query)", "send_email(to, subject, body)", "create_invoice(client_id, amount)". Tools haben Input-Schemata (JSON-Schema) und liefern strukturierte Outputs. Tools können Seiteneffekte haben.

Prompts. Vordefinierte Prompt-Templates, die ein MCP-Server bereitstellt – z.B. "summarise_meeting", "draft_reply". Diese sind optional und Mai 2026 weniger zentral als Resources und Tools.

Transport. MCP nutzt JSON-RPC 2.0 über zwei mögliche Transporte: stdio (Server läuft als Sub-Prozess des Clients, einfach für lokale Server) oder SSE/HTTP (Server ist ein Web-Service, gut für remote/cloud-Server). Mai 2026 wird beides in Production genutzt; stdio für Desktop-Apps und lokale Tools, HTTP für Cloud-MCP-Server.

Praktischer Ablauf. Ein Client (Claude Desktop, Cursor, eine eigene Agent-Pipeline) verbindet sich beim Start mit einem oder mehreren MCP-Servern. Der Client fragt jeden Server: welche Resources, welche Tools, welche Prompts hast du? Der Server antwortet mit einem Katalog. Der Client übersetzt diesen Katalog in das native Tool-Use-Format des LLM-Anbieters (Anthropic-Format, OpenAI-Format, ...). Wenn das Modell ein Tool aufruft, sendet der Client den Aufruf an den passenden MCP-Server, erhält das Ergebnis, gibt es ans Modell zurück. Für das Modell sieht das aus wie ein normaler Tool-Call. Für den Server-Entwickler ist es ein generisches Protokoll, nicht ein anbieterspezifisches API.

Open-Source-Server. Mai 2026 existieren MCP-SDKs in TypeScript, Python, Go, Rust, Java. Einen einfachen MCP-Server zu bauen (z.B. für eine eigene API) dauert mit dem TypeScript-SDK 30-90 Minuten. Komplexe Server (z.B. mit Datenbank-Schema-Introspektion und Auth) brauchen 1-3 Tage. Die offizielle Server-Liste (modelcontextprotocol.io/servers) wächst Mai 2026 wöchentlich.

MCP-Einführung in 5 Schritten

1. 01Use-Case identifizieren: welche Datenquelle oder welcher Service soll für wie viele Tools/Anwendungen zugänglich werden? Wenn nur 1 Tool und 1 Anbieter, MCP eventuell unnötig.
2. 02Server-Inventar prüfen: gibt es bereits einen offiziellen MCP-Server (modelcontextprotocol.io/servers) für diese Datenquelle? Wenn ja, einbinden statt nachbauen.
3. 03Server-Architektur entscheiden: lokaler stdio-Server (läuft als Sub-Prozess, einfach, sicher) oder Remote-HTTP-Server (mehrere Clients, Cloud-deployment, braucht eigene Auth).
4. 04Server bauen mit MCP-SDK (TypeScript oder Python): Resources und Tools mit JSON-Schema definieren, Auth wählen, Eval-Tests schreiben. Typisch 30 Min bis 3 Tage je nach Komplexität.
5. 05Clients einbinden: Konfiguration in Claude Desktop, Cursor, eigene Agent-Pipeline. Versions-Pinning, Audit-Logging der MCP-Calls, Monitoring.

Wann MCP nutzen

MCP ist Mai 2026 die richtige Wahl in fünf Konstellationen.

Erstens: Sie nutzen mehrere LLM-Anbieter. Sobald Sie Claude UND GPT (oder Gemini, Mistral, lokales Ollama) parallel im Einsatz haben, sparen MCP-Server die doppelte oder dreifache Integrations-Arbeit. Eine Postgres-Anbindung über MCP ist sofort in allen MCP-fähigen Clients verfügbar.

Zweitens: Sie nutzen Desktop-Tools wie Claude Desktop, Cursor, Continue. Diese Clients haben MCP nativ eingebaut. Wenn Sie Ihre eigene Datenbank, Ihre eigenen Dateien oder Ihre eigenen Services für Claude in der Desktop-App zugänglich machen wollen, ist MCP der Weg – ohne MCP geht das schlicht nicht.

Drittens: Sie wollen einen Werkzeug-Katalog langfristig aufbauen. Ein KMU, das über 12-24 Monate eine wachsende Sammlung interner Tools (Bexio-Connector, Mandanten-DB-Server, internes Dokument-Suche-Tool, GwG-Prüf-Service) baut, sollte das als MCP-Server tun. Diese Bibliothek wächst additiv, ohne pro Anbieter umgeschrieben werden zu müssen.

Viertens: Sie wollen Drittanbieter-Tools nutzen. Es gibt Mai 2026 öffentliche MCP-Server für Slack, GitHub, Google Drive, Notion, Linear, Sentry usw. Einbinden statt nachbauen – typisch 5-30 Minuten pro Server für Konfiguration und Auth.

Fünftens: Sie wollen Multi-Tenant-Trennung. Ein MCP-Server kann pro Mandanten-Kontext unterschiedliche Resources/Tools exponieren. Das ist sauberer als Filter im Anbieter-spezifischen Tool-Code.

Anwendungsbeispiel: Eine Treuhand baut einen MCP-Server, der drei Tools hat – `search_bexio`, `lookup_client`, `draft_invoice`. Dieser Server wird parallel von Claude Desktop (für interne Mitarbeiter-Recherche), einer eigenen Mandanten-Chat-Anwendung mit GPT-4 (für Mandanten-Selbstauskunft), und einem Batch-Skript mit Mistral-EU (für nächtliche Sammelverarbeitung) genutzt. Drei Anwendungen, drei Modelle, ein Server.

Wann MCP zu viel ist

Drei Fälle, in denen MCP Overhead ohne Nutzen produziert.

Erstens: einzelne Anwendung, einzelner Anbieter, einzelnes Werkzeug. Wenn Sie eine kleine Anwendung mit Claude und einem einzigen Bexio-Aufruf bauen, ist der native Anthropic-Tool-Use-Aufruf direkt der einfachste Weg. MCP einzuführen bringt zusätzliche Schicht ohne Gewinn.

Zweitens: Latenz-kritische Anwendungen. MCP fügt 5-50 ms pro Tool-Call hinzu (JSON-RPC-Roundtrip via stdio oder HTTP). Für typische Chat-Anwendungen ist das irrelevant. Für Voice-Agents in Echtzeit oder sehr enge Inference-Schleifen kann das spürbar werden.

Drittens: Sicherheits-kritische Tools mit eigener Auth-Logik. MCP-Server haben eigene Auth-Modelle (lokale stdio-Server vertrauen dem Client; HTTP-Server brauchen OAuth/API-Key). Bei sehr sensiblen Tools (z.B. Zahlungs-Aufträge) ist es manchmal sauberer, die Auth-Logik direkt in der Anwendung zu haben und nicht durch eine MCP-Schicht zu vermitteln. Mai 2026 erweitern sich MCP-Auth-Patterns rasch, aber jeder neue Server bringt Auth-Konfigurations-Komplexität.

Sicherheits-Falle. Wer remote MCP-Server (HTTP-MCP) einbindet, gibt diesem Server potentiell Zugriff auf seine LLM-Konversations-Daten. Bei vertraulichen Anwendungen (Mandanten-Daten, Berufsgeheimnis StGB 321) niemals einen Drittanbieter-MCP-Server für sensible Resources nutzen, ohne den Anbieter unter Datenschutz-Vertrag (DPA) zu haben. Lokale stdio-Server sind sicherer, weil sie unter eigener Kontrolle laufen.

Reifegrad-Hinweis. MCP ist Mai 2026 stabil, aber jünger als HTTP. Spezifikations-Versionen entwickeln sich weiter (Hauptversionen Nov 2024, März 2025, Sep 2025, März 2026), Server-Implementierungen sind verschieden gut getestet. Bei Produktiv-Einsatz: Server-Quelle prüfen, eigene Eval-Suite, Versions-Lock.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Model Context Protocol – Specification and SDKs · 2026-05
2. Anthropic – Introducing MCP (Announcement) · 2024-11
3. OpenAI – MCP Support in Agents SDK · 2025-03
4. Awesome MCP Servers – Community Catalogue · 2026-05