Wer heute eine ernstzunehmende Anwendung mit Sprachmodellen baut, kennt das Gefühl: Jedes Modell, jeder Anbieter, jede Plattform hat sein eigenes Verständnis davon, wie ein Modell ein Werkzeug aufruft. Function Calling bei OpenAI, Tool Use bei Anthropic, Extensions bei Google, Plugins bei diversen anderen — die Signaturen ähneln sich, sind aber inkompatibel. Jede Integration wird N-mal gebaut, jede Änderung am Backend wandert N-mal durch die Codebase, und der Schritt zu einem neuen Provider kostet eine Woche statt einen Tag.
Genau dieses Problem adressiert das Model Context Protocol. Es ist nicht der erste Versuch, eine einheitliche Schnittstelle zu definieren, aber der erste, hinter dem genug Marktgewicht steht, um eine echte Chance auf Adoption zu haben. Dieser Beitrag erklärt MCP technisch — ohne hübsche Vergleiche, mit dem ehrlichen Stand der Dinge inklusive der Stellen, an denen es noch nicht rund läuft.
Was MCP technisch ist
MCP ist ein Open-Source-Protokoll, das von Anthropic Ende 2024 veröffentlicht wurde. Es definiert, wie ein KI-Client (zum Beispiel ein Chat-Frontend oder eine Agenten-Runtime) mit einem Server kommuniziert, der externe Fähigkeiten bereitstellt — Tools, Daten und Prompt-Vorlagen.
Das Protokoll ist absichtlich pragmatisch gehalten: JSON-RPC 2.0 als Transportgrundlage, klar definierte Methoden, ein Capability-Negotiation-Schritt am Anfang jeder Session. Wer schon einmal mit JSON-RPC gearbeitet hat, fühlt sich sofort zuhause. Das ist gewollt — MCP soll an einem Nachmittag implementierbar sein, nicht an einem Quartal.
Die Spezifikation kennt im Kern drei Server-Primitive:
- Tools — ausführbare Funktionen, die das Modell mit Argumenten aufrufen kann
- Resources — adressierbare Daten, die der Client lesen kann (Dateien, Records, Metriken)
- Prompts — vordefinierte Prompt-Vorlagen, die der Server anbietet
Diese Trennung ist nicht kosmetisch. Sie hat direkte Konsequenzen für Caching, Berechtigungen und Modellverhalten. Ein Tool-Aufruf erzeugt Seiteneffekte; eine Resource-Lese-Operation sollte idempotent sein; ein Prompt-Template ist Inhalt, nicht Aktion.
Die Architektur kurz und ehrlich
Drei Akteure, klar voneinander getrennt:
Host — die Anwendung, in der das Modell läuft (Chat-Client, Agenten-Framework, IDE-Extension). Der Host besitzt das Modell, das Konversationsfenster und letztlich die Entscheidung, welcher Server kontaktiert wird.
Client — eine MCP-Sprechinstanz innerhalb des Hosts. Pro Server-Verbindung existiert ein Client; der Host kann mehrere Clients gleichzeitig laufen lassen und Tools verschiedener Server gemischt anbieten.
Server — die Komponente, die Tools, Resources und Prompts bereitstellt. Server können lokal als Prozess laufen oder remote per HTTP angesprochen werden.
Die Trennung Host/Client ist wichtiger, als sie zunächst wirkt. Sie entkoppelt die Modell-Interaktion vom Protokoll-Handling und ermöglicht es, dasselbe Server-Ökosystem aus völlig unterschiedlichen Hosts zu nutzen — Desktop-Clients, Editoren, Custom-Agenten, Server-zu-Server-Setups.
Transport-Schichten
Aktuell sind zwei Transports etabliert:
- stdio — Server läuft als lokaler Prozess, Kommunikation über Standard-In/Out. Einfach, performant, ideal für Desktop-Tools und lokale Integrationen.
- HTTP + SSE / Streamable HTTP — Server läuft remote, Client kommuniziert über HTTP. Streaming-fähig, für Cloud-Setups und mandantenfähige Dienste.
Der HTTP-Transport hat sich in den letzten Iterationen mehrfach verändert. Wer Clients oder Server baut, sollte gezielt auf die aktuelle Variante setzen und ältere SSE-only-Implementierungen migrieren — das ist die Stelle, an der die meisten Inkompatibilitäten zwischen Tools heute auftreten.
Capability Negotiation
Am Anfang jeder Session handeln Client und Server aus, welche Features unterstützt werden. Das ist mehr als ein höfliches Handshake — es erlaubt dem Protokoll, in Versionen vorwärtskompatibel zu wachsen, ohne ältere Implementierungen zu brechen. Wer einen Server schreibt, sollte diese Negotiation ernst nehmen und nicht hartcodieren, was der Client kann.
Was MCP gegenüber den Vorgängern wirklich anders macht
Tool-Use-Mechanismen gab es bei einzelnen Anbietern lange vor MCP. Der Unterschied liegt weniger in der reinen Funktionalität als in vier strukturellen Eigenschaften:
Provider-Agnostik per Design. Function Calling bei OpenAI ist an die OpenAI-API gekoppelt. MCP-Server kennen den dahinter sitzenden Provider nicht und müssen ihn nicht kennen. Derselbe Server funktioniert mit jedem konformen Client.
Server-initiierte Discovery. Der Client muss die Tools nicht hartkodiert kennen, sondern fragt den Server beim Verbinden. Das ermöglicht dynamische Tool-Sets, die sich zur Laufzeit ändern — ein Backend kann sein Tool-Portfolio ohne Client-Update erweitern.
Stateful Sessions. Eine Session erlaubt mehrfach hin und her, Resource-Lesungen vor und nach Tool-Aufrufen, Streaming partieller Ergebnisse. Klassische REST-Plugin-APIs waren strikt request/response — viele agentische Muster gehen damit nicht.
Sampling als Inversionspunkt. Ein Server kann den Client bitten, im Namen des Modells weitere Inferenz auszuführen. Das öffnet Multi-Step-Workflows, in denen der Server orchestriert und das Modell als Werkzeug nutzt — nicht umgekehrt. Sicherheitstechnisch ist das ein eigenes Thema (dazu unten mehr).
Diese vier Punkte zusammen sind der Grund, warum MCP nicht nur ein hübscherer Tool-Use-Standard ist, sondern eine neue Layer im Stack.
Wo MCP heute schon belastbar funktioniert
In den letzten zwölf Monaten haben sich klare Sweet-Spots herauskristallisiert:
Editor- und IDE-Integration
Lokale Server, die einem Coding-Agenten Zugriff auf Repository-Operationen, Tests, Linter und Build-Werkzeuge geben. Hier ist MCP heute der De-facto-Standard. Der stdio-Transport passt perfekt, Latenz ist minimal, Security-Modell überschaubar.
Daten-Lookup für Wissensarbeiter
Server, die einen Slack-Workspace, eine Notion-Datenbank, ein Confluence-Wiki oder ein CRM lesbar machen. Das Read-Only-Szenario ist robust, weil die Side-Effects fehlen — Berechtigungsmodell und Audit-Trail bleiben handhabbar.
Spezialisierte Werkzeuge in agentischen Setups
Agenten, die mehrere fokussierte Server kombinieren statt einen Universal-Endpunkt anzusprechen. Ein Web-Such-Server, ein Datenbank-Server, ein File-Server — jeder mit klarem Verantwortungsbereich, alle aus demselben Host orchestriert.
Vendor-Tools mit Self-Service-Integration
Anbieter, die ihren Kunden einen MCP-Server bereitstellen, anstatt eine proprietäre Integration mit dem AI-Stack des Kunden zu bauen. Der Vendor wartet einen Server, der Kunde verbindet ihn mit seinem bevorzugten Host. Wartungslast ist deutlich besser als bei direkten Integrationen.
Wo es heute noch hakt
Wer MCP in Produktion bringt, sollte die offenen Baustellen kennen — nicht weil sie Showstopper sind, sondern weil sie Architektur-Entscheidungen beeinflussen.
Authentifizierung und Autorisierung
Die Auth-Story ist im Lauf des letzten Jahres mehrfach umgebaut worden. Die OAuth-2.1-basierte Variante mit Dynamic Client Registration ist heute der empfohlene Weg, ist aber in der Praxis komplex und in vielen Hosts erst teilweise umgesetzt. Wer einen Server schreibt, hat oft die Wahl zwischen „mit ausgewählten Hosts kompatibel und sauber“ oder „mit vielen Hosts kompatibel und mit Bauchschmerzen“. Diese Lücke schließt sich, ist aber noch nicht zu.
Mandantenfähigkeit
Das Protokoll selbst sagt wenig über Multi-Tenancy. Wer einen Server für viele Nutzer betreibt, muss Auth, Rate-Limiting, Audit, Datenisolation und Plan-Limits selbst gestalten. Es gibt Muster, aber kein Referenz-Framework, das man einfach nehmen kann.
Versionierung von Tools
Tools haben kein eingebautes Versionsschema. Wenn ein Server ein Tool-Signature ändert, gibt es keinen sauberen Mechanismus, um älteren Clients die alte Variante weiter anzubieten. In der Praxis behilft man sich mit suffixierten Tool-Namen und deprecation-Hinweisen — funktioniert, ist aber kein Designziel des Standards.
Sampling als Sicherheitsthema
Ein Server, der den Client um Modell-Inferenz bitten kann, ist eine starke Fähigkeit — und ein attraktives Ziel für Prompt-Injection. Wer Sampling aktiviert, sollte sich klar machen, dass damit ein nicht vertrauenswürdiger Server potenziell Modell-Outputs steuern kann. Best Practices entstehen gerade, sind aber noch nicht etabliert.
Beobachtbarkeit
Tracing, strukturiertes Logging, Replay von Sessions — die Tooling-Landschaft ist jung. Wer Server produktiv betreibt, baut sich Observability heute noch weitgehend selbst. Das ist machbar, sollte aber im Aufwand eingeplant werden.
Resource-Semantik in der Praxis
Resources sind im Protokoll sauber definiert, werden in den meisten realen Servern aber bisher kaum genutzt. Die meisten Server bieten Tools mit Read-Operations an, statt die Resource-API zu verwenden. Das hat Folgen für Caching und Modellverhalten — ein Tool-Aufruf wird vom Modell anders behandelt als ein Resource-Read.
Praktische Hinweise für die Implementierung
Wenn Sie einen MCP-Server oder -Client schreiben, lohnen sich einige Entscheidungen früh.
Schema-Design
Tool-Schemas (über JSON Schema) sollten so streng wie möglich, aber so freundlich wie nötig sein. Required-Felder klar benennen, Default-Werte explizit dokumentieren, Beschreibungen für jedes Feld liefern. Das Modell liest diese Beschreibungen — eine gute Description ist oft die Differenz zwischen korrektem Tool-Einsatz und Halluzination.
Idempotenz und Side-Effects
Markieren Sie in der Tool-Description deutlich, was Seiteneffekte hat. Modelle agieren beim Aufruf vorsichtiger, wenn sie wissen, dass eine Aktion irreversibel ist. „Sends an email“ ist eine bessere Description als „Triggers communication“.
Fehlerbehandlung
Strukturierte Fehler statt freier Texte. Das Modell kann mit {"error": "rate_limited", "retry_after": 30} weit besser umgehen als mit „Es ist etwas schiefgelaufen“. Klare Fehlerklassen erlauben es einem Agenten, sinnvolle Recovery-Strategien zu wählen.
Streaming dort einsetzen, wo es Sinn ergibt
Lange laufende Operationen sollten partielle Ergebnisse streamen. Das verbessert die User Experience im Host und gibt dem Modell zwischenzeitliche Information, um zu entscheiden, ob es die Operation abbrechen sollte.
Test-Setup
Ein Mock-Client gegen den eigenen Server ist Pflicht. Das MCP-Inspector-Tool eignet sich für manuelles Testen, für CI braucht es eigene Test-Harnesses. Server ohne automatisierte Tests entgleisen sehr schnell, sobald Tool-Schemas wachsen.
Sicherheit als Server-Verantwortung
Authentifizierung, Rate-Limiting, Input-Validierung und Output-Sanitization gehören auf den Server, nicht auf den Client. Der Host kann nicht wissen, was ein Tool darf — der Server muss es wissen und durchsetzen.
Wo sich der Standard hinentwickelt
Drei Linien, die heute klar erkennbar sind:
- Standardisierung der Auth-Story — die OAuth-Variante wird sich konsolidieren, mehr Hosts werden sie nativ unterstützen, der Migrationspfad von einfachen Tokens wird klarer.
- Resources gewinnen Bedeutung — sobald Caching und Subscription-Semantik in mehr Hosts implementiert sind, werden datenintensive Use Cases von Tool- auf Resource-API migrieren.
- Agentische Primitive wachsen — Sampling, langlaufende Operationen, Cancellation-Signale, Progress-Reports werden sauberer modelliert.
Was unklar bleibt, ist die Frage der Governance. Anthropic hat den Standard veröffentlicht, aber eine breite Stakeholder-Governance fehlt bislang. Ob MCP in Richtung eines wirklich neutralen Standards mit eigenem Gremium wandert oder ein de-facto-offener Standard unter Anthropic-Federführung bleibt, ist offen.
Was ich für Sie entwickle
Ich begleite Teams, die MCP ernsthaft einsetzen wollen — sowohl auf der Server- als auch auf der Client-Seite. Der Fokus liegt darauf, dass das Setup produktionsreif wird und nicht als Demo stehen bleibt.
MCP-Server für bestehende Backends — Wrapper-Server, die ein existierendes API, ein CRM oder eine interne Datenbank MCP-konform exponieren, inklusive sauberer Tool-Schemata, strukturierter Fehler und differenzierter Berechtigungen.
Mandantenfähige Server-Setups — Architektur und Implementierung von Auth, Rate-Limiting, Audit-Trails und Mandantentrennung für Server, die mehrere Kunden bedienen sollen.
Host- und Client-Integration in eigene Anwendungen — wenn ein Produkt nicht über einen Standard-Host laufen soll, sondern MCP-Clients direkt in der eigenen Anwendung verbaut werden — Capability-Negotiation, Tool-Registry, Sicherheits-Sandboxing inklusive.
Migrationsbegleitung von proprietären Tool-Use-Setups — bestehende Function-Calling-Integrationen schrittweise auf MCP umstellen, ohne dass die bestehenden Workflows abreißen.
Observability für MCP-Setups — strukturiertes Logging, Tracing, Session-Replay und Alerts, sodass Server-Verhalten in Produktion nachvollziehbar wird.
Security-Review für bestehende MCP-Implementierungen — gezielter Blick auf Authentifizierung, Sampling-Konfiguration, Tool-Berechtigungen und Prompt-Injection-Risiken. Ergebnis: konkrete Härtungs-Empfehlungen, priorisiert nach Risiko.
Wer mit MCP starten möchte, braucht keinen großen Architekturwurf — ein erster, klar abgegrenzter Server für ein konkretes internes System ist meist der bessere Einstieg als das ganz große Plattform-Setup.
Fazit
MCP ist kein Hype, sondern eine ernstzunehmende Standardisierungs-Initiative, hinter der genug Marktgewicht steht, um eine echte Chance auf Durchsetzung zu haben. Die Protokollidee ist sauber, die Implementierung pragmatisch, das Ökosystem wächst.
Wer heute Sprachmodelle ernsthaft in Anwendungen baut, sollte MCP zumindest als Option auf dem Tisch haben — nicht weil es schon in jeder Dimension reif ist, sondern weil die Alternative für die nächsten Jahre eine Vervielfältigung des Integrationsaufwands ist. Die Lücken (Auth, Mandantenfähigkeit, Versionierung, Observability) sind real, aber lösbar und werden im Standard und im Tooling sichtbar schmaler.
Der pragmatische Weg ist nicht „alles auf MCP“, sondern „MCP dort, wo der Mehrwert klar ist“: Editor-Integration, interne Daten-Lookups, spezialisierte Tools in agentischen Setups, Self-Service-Integration für Vendor-Tools. Aus diesem Fundament lässt sich nach hinten heraus systematisch ausbauen — sobald sich die Standard-Reife in den noch offenen Bereichen einstellt.
