Wenn Sie dies über die Suche nach „what is MCP“ oder „model context protocol JSON-RPC“ gefunden haben, befinden Sie sich wahrscheinlich in einer von zwei Situationen. Entweder haben Sie vier Artikel über MCP gelesen und können trotzdem nicht in einem Satz erklären, was es eigentlich tut, oder etwas in Ihrer KI-Toolchain verhält sich seltsam und jemand hat MCP als Ursache genannt. In beiden Fällen sind Sie hier richtig.
MCP wird als vieles beschrieben: als Framework, Plattform, KI-Connector oder als Möglichkeit, LLMs Tools bereitzustellen. Die meisten dieser Beschreibungen liegen technisch nahe an der Wahrheit, verfehlen aber den Mechanismus völlig. MCP ist eine Spezifikation für ein Kommunikationsprotokoll – ein definierter Satz an Regeln dafür, wie eine KI-Anwendung und ein Server, der Tools bereitstellt, miteinander kommunizieren. Es basiert auf JSON-RPC 2.0. Das ist alles. Alles andere ist das, was Sie darauf aufbauen.
Die überprüfbare Aussage, die dieser Artikel vertritt: MCP löst das NxM-Integrationsproblem, indem es LLMs einen standardisierten, transportunabhängigen Weg bietet, externe Tools und Daten über ein klar definiertes Basisprotokoll auf Grundlage von JSON-RPC 2.0 zu erreichen – und es funktioniert gerade deshalb, weil es die Messaging-Ebene nicht von Grund auf neu erfunden hat.
Was die meisten Übersichten vollständig auslassen
- MCP ist eine auf JSON-RPC 2.0 basierende Protokollspezifikation, keine Plattform – diese Unterscheidung verändert, wie Sie es implementieren.
- Über JSON Schema erfahren LLMs vor dem Aufruf, welche Argumente ein Tool akzeptiert; ohne Schema entsteht Verwirrung zur Laufzeit, kein Build-Fehler.
- Die Client-/Server-Aufteilung in MCP ist nicht dieselbe wie bei REST: Beide Seiten können Anfragen initiieren, was die meisten Entwickler beim ersten Mal überrascht.
Das Problem, das MCP löst: LLM-Isolation und die NxM-Integrationshölle
Vor MCP bedeutete die Verbindung eines KI-Modells mit einem externen Tool, jedes Mal eine eigene Integration zu entwickeln. Wenn Sie drei KI-Modelle und fünf Tools hatten, mussten Sie potenziell 15 unterschiedliche Connectoren erstellen, warten und aktualisieren, sobald sich auf einer der beiden Seiten etwas änderte. Das ist das NxM-Problem: N Modelle multipliziert mit M Tools, und die Matrix wächst schnell.
Ich sehe dieses Muster immer wieder im Support: Teams hatten dieselbe Logik zum Lesen von Dateien oder Abfragen von Datenbanken bereits in drei unterschiedliche KI-Agenten eingebaut, weil es keinen Standardweg gab, sie zu teilen. Ein Team hatte einen Python-Connector, ein anderes einen TypeScript-Wrapper, ein drittes nutzte einen curl-basierten Workaround. Unterschiedliche Codebasen, gleiches Ergebnis. Niemand verwendete etwas wieder, weil nichts auf Wiederverwendbarkeit ausgelegt war. Entwicklung und Debugging erfolgten für jede Implementierung isoliert.
Die OpenAI-Function-Calling-API hat dieses Problem speziell für ChatGPT eingegrenzt. Sie war jedoch proprietär – eine Lösung für einen Host, keine Spezifikation, die andere KI-Modelle übernehmen konnten. Das breitere Ökosystem brauchte etwas anderes: einen Standard, den jeder Host implementieren und den jeder Tool-Server sprechen kann, ohne für jede Kombination eigenen Code zu benötigen.
MCP ist die Antwort von Anthropic darauf. Als offene Spezifikation mit öffentlichen SDKs veröffentlicht, definiert es eine gemeinsame Schnittstelle: Eine Chat-Oberfläche kann sich genauso mit einem MCP-Server verbinden wie jeder andere Host und dabei demselben Protokoll folgen. Die KI-Modelle auf der einen Seite und die Tools auf der anderen sprechen eine gemeinsame Sprache statt einer maßgeschneiderten. Die NxM-Matrix schrumpft auf N+M.
Was ist das Basisprotokoll in MCP und warum JSON-RPC es antreibt
Hier verlieren die meisten MCP-Übersichten ihre Leser. Sie beschreiben, was MCP Ihnen ermöglicht – LLMs Tools geben, Ressourcen lesen, Prompt-Vorlagen verwenden –, lassen aber aus, was es mechanisch eigentlich ist. Die MCP-Spezifikation formuliert es direkt: Alle Nachrichten zwischen MCP-Clients und -Servern müssen der JSON-RPC-2.0-Spezifikation folgen und die JSON-RPC-2.0-Nachrichtentypen Request, Response und Notification als Basisprotokoll verwenden.
Das ist kein Detail. Das ist die Architektur. MCP ist kein neues Messaging-Format. Es ist ein Satz von Regeln, der auf einem bestehenden, gut verstandenen Format aufbaut. Die JSON-RPC-2.0-Spezifikation definiert ein zustandsloses, schlankes und transportunabhängiges RPC-Protokoll, das JSON als Datenformat verwendet. „Transportunabhängig“ ist der wichtige Teil: JSON-RPC ist es egal, ob Nachrichten über stdio, HTTP, WebSockets oder etwas anderes übertragen werden. MCP übernimmt diese Flexibilität direkt. Deshalb kann derselbe MCP-Server mit einer lokalen IDE über stdin/stdout und mit einem entfernten Cloud-Service über HTTP kommunizieren, ohne das Nachrichtenformat zu ändern.
MCP ist auch kein proprietäres Tool-Format von Anthropic. Die Analyse zu Enterprise-Deployments von Synvestable aus dem Jahr 2026 schätzte die MCP-Adoption unter Fortune-500-Unternehmen innerhalb von 18 Monaten nach Verfügbarkeit auf rund 28 % – angesichts teilweise unvollständiger Datenoffenlegung eher ein Indikator als ein exakter Wert, doch das Signal ist eindeutig: Diese Spezifikation erreicht die Produktion in Organisationen, die sich nicht auf Anthropic-spezifische Technologien standardisieren. Der Grund dafür ist, dass JSON-RPC-basierte Interoperabilität real ist und keine Marketingsprache.
Stellen Sie es sich so vor: MCP liefert dem Ökosystem die Spezifikation. JSON-RPC gibt MCP seine Nachrichten-Grammatik. JSON Schema gibt jedem Tool-Aufruf seinen Wortschatz. Diese drei Ebenen sind unterschiedlich, und ihre Vermischung ist der Ausgangspunkt für die meisten Implementierungsprobleme.
Warum JSON-RPC 2.0 und nicht REST oder GraphQL
Die ehrliche Antwort auf diese Frage lautet meist: „Weil es besser passt.“ Das ist nicht besonders befriedigend, bis Sie verstehen, was „passen“ hier bedeutet.
REST ist ressourcenorientiert. Sie modellieren die Welt als Substantive (Endpunkte) und Verben (HTTP-Methoden). Das funktioniert gut für CRUD-Operationen, wirkt aber bei Dingen wie „Rufe diese Funktion mit diesen Parametern auf und gib mir ein Ergebnis“ umständlich. JSON-RPC ist aktionsorientiert. Die gesamte API ist ein einzelner Endpunkt, und Sie rufen eine benannte Methode auf. Das passt sauber zu „Rufe dieses Tool mit diesem Payload auf“.
GraphQL löst ein anderes Problem: das Abrufen strukturierter Daten aus einem Graphen. Dafür ist es leistungsstark. Hier ist es überdimensioniert.
Was JSON-RPC 2.0 speziell für MCP nützlich macht, ist der Notification-Typ. Eine Notification ist eine einseitige JSON-RPC-Nachricht – sie erfordert keine Antwort. MCP verwendet Notifications beispielsweise für Fortschrittsupdates und Capability-Signale, bei denen der Absender nicht warten muss. JSON-RPC unterstützt außerdem das Senden mehrerer Anfragen als Batch, was wichtig ist, wenn ein KI-Agent mehrere Tool-Aufrufe effizient parallelisieren muss. REST hat für keines der beiden Muster native Entsprechungen. JSON verarbeitet die Payloads durchgängig und hält das Format konsistent sowie mit jeder Sprache mit JSON-Bibliothek parsbar.
Wie JSON Schema mit dem Protokoll verbunden ist
Dies ist das Detail, das die meisten Übersichten auslassen – und genau der Teil, der MCP-Tools maschinenlesbar statt nur maschinell erreichbar macht.
Wenn ein MCP-Server ein Tool bereitstellt, registriert er nicht nur einen Namen. Er liefert ein Schema – konkret eine JSON-Schema-Definition –, die beschreibt, welche Eingaben das Tool akzeptiert und wie diese Eingaben aussehen müssen. Die MCP-Spezifikation verlangt JSON Schema 2020-12 als Standarddialekt.
Warum ist das wichtig? Weil ein LLM beim Aufruf eines Tools die Argumente nicht errät. Es liest das Schema. Das Schema ist der Vertrag zwischen Tool-Server und LLM: „Dieses Tool akzeptiert ein Objekt mit einem erforderlichen Feld namens query vom Typ String und einem optionalen Feld namens limit vom Typ Integer.“ Das LLM kann aus dieser Beschreibung automatisch einen gültigen Aufruf erstellen. Ohne das Schema sind verfügbare Tools undurchsichtig – der KI muss per Prompt mitgeteilt werden, wie sie sie aufruft, statt dies über das Protokoll selbst zu erkennen.
Aus Support-Perspektive: Die häufigsten Fehler bei Tool-Aufrufen, die ich sehe, sind Schema-Abweichungen, bei denen das LLM ein Params-Objekt sendet, das nicht dem entspricht, was der Server deklariert hat. Der Fehler ist meist undurchsichtig, weil die Validierung serverseitig erfolgt und die Antwort nur „invalid parameters“ lautet. Prüfen Sie zuerst das Schema. Das beseitigt die Unklarheit, bevor die Debugging-Spirale beginnt.
MCP-Kernkomponenten: Hosts, Clients und Server
Die Terminologie verwirrt viele Menschen, auch diejenigen, die REST und RPC gut verstehen. MCP verwendet die Begriffe „Client“ und „Server“ auf eine Weise, die mit ihrer üblichen Bedeutung verwandt, aber nicht identisch ist. Wenn Sie dies falsch verstehen, entsteht ein mentales Modell, in dem das LLM der Client ist. Das führt zu falschen Annahmen darüber, wo Fehler auftreten, wenn etwas nicht funktioniert.
MCP kennt drei strukturelle Rollen:
Der Host ist die Anwendung, die der Benutzer tatsächlich ausführt. Claude Desktop ist ein Host. Cursor ist ein Host. Eine benutzerdefinierte KI-Anwendung, die Ihr Team entwickelt hat und die ein LLM aufruft, ist ein Host. Der Host ist für die Benutzererfahrung und die Verwaltung des LLM verantwortlich. Er enthält einen MCP-Client.
Der MCP-Client befindet sich im Host. Er ist der Protokoll-Handler – die Komponente, die MCP und JSON-RPC sprechen kann, Verbindungen zu einem oder mehreren MCP-Servern verwaltet, Anfragen weiterleitet und Antworten an das LLM zurückgibt. Der häufige Fehler besteht darin, den MCP-Client als passiv zu betrachten, wie einen einfachen HTTP-Client, der Anfragen abschickt. Das ist er nicht. Der MCP-Client übernimmt die Capability-Erkennung und verwaltet den Sitzungsstatus. Das LLM selbst kennt die Protokolldetails nicht; das ist Aufgabe des Clients.
Der MCP-Server stellt Tools, Ressourcen und Prompts bereit. Er muss kein Webserver im traditionellen Sinn sein. Es handelt sich um einen Prozess, der MCP-JSON-RPC-Nachrichten empfangen und darauf antworten kann. Der Server kann ein lokaler Subprozess sein, der über stdio kommuniziert, oder ein entfernter Service hinter einem HTTP-Endpunkt. Aus Sicht des Clients sieht das Protokoll in beiden Fällen gleich aus.
Die Verwirrung, die ich im Support meist sehe, sieht so aus: Ein Entwickler erstellt einen MCP-Server, verbindet ihn mit einer KI-Anwendung und fragt sich dann, warum der „Client“ – den er als nutzerseitige App identifiziert hat – Anfragen sendet, die der Server nicht erwartet. Die Antwort ist in der Regel, dass der MCP-Client innerhalb des Hosts der tatsächliche Kommunikationspartner ist und eine eigene Initialisierungs- und Capability-Aushandlungssequenz hat, die vor jedem Tool-Aufruf ausgeführt werden muss.
Dort beginnt das Ticket normalerweise.
Was ein MCP-Server tatsächlich bereitstellt
Ein MCP-Server kommuniziert über drei Primitive. Nur drei. Das ist der gesamte Wortschatz.
Tools sind ausführbare Funktionen. Sie nehmen Eingaben entgegen, führen etwas aus und geben Ergebnisse zurück. „Durchsuche diese Datenbank“, „Sende diese E-Mail“, „Führe diese Abfrage aus“ – das sind alles Tools. Das LLM ruft sie auf, wenn es eine Aktion ausführen oder berechnete Ergebnisse abrufen muss. Mit JSON Schema definierte Tools sind automatisch auffindbar.
Ressourcen sind lesbare Daten. Dateien, Datenbankeinträge, API-Antworten, Konfigurationswerte – alles, was das LLM lesen muss, aber nicht als Funktion aufrufen muss. Ressourcen sind externe Datenquellen und Tools, die Kontext bereitstellen, ohne eine Funktionsausführung zu erfordern.
Prompts sind vorlagenbasierte Interaktionsmuster. Ein Prompt in MCP ist eine vordefinierte Methode, eine Interaktion zu strukturieren – wiederverwendbare Prompt-Vorlagen, die der Host auswählen und das LLM mit bestimmten Parametern nutzen kann. Betrachten Sie sie als benannte Gesprächseinstiege mit Platzhaltern. Ein Prompt könnte „Fasse dieses Dokument zusammen“ mit einem Dokumentparameter sein, den der Server bereitstellt, damit der Host ihn als vom Benutzer auswählbare Option anbieten kann.
Das ist die vollständige Menge. Jeder MCP-Server, auf den Sie stoßen, stellt eine Kombination dieser drei Elemente bereit. Bevor Sie einen MCP-Server erstellen oder debuggen, lautet die erste Frage immer: Welche Primitive stellt er tatsächlich bereit, und sind sie korrekt deklariert?
Wofür MCP-Clients verantwortlich sind
MCP-Clients sind nicht passiv. Dies ist das Implementierungsdetail, das die meisten Entwickler beim Aufbau ihrer ersten MCP-angebundenen Anwendung trifft.
Der Client befindet sich im Host und verwaltet die Verbindung zu einem oder mehreren MCP-Servern. Er übernimmt den Prozess der Capability-Erkennung: Während der Initialisierung fragt der Client den Server, was dieser unterstützt, und der Server antwortet mit einer Liste seiner verfügbaren Tools, Ressourcen und Prompts. Ab diesem Zeitpunkt weiß der Client, was das LLM aufrufen kann. Das LLM selbst befragt den Server nicht direkt; der Client verwaltet diesen Status in seinem Namen.
Clients sind außerdem für das Lifecycle-Management verantwortlich: für den Aufbau der Verbindung, die Aufrechterhaltung der Sitzung und die Behandlung von Verbindungsabbrüchen. Wenn der Server mitten in einer Sitzung ausfällt, muss der Client entscheiden, was zu tun ist – einen Fehler anzeigen, eine Wiederverbindung versuchen oder kontrolliert in die Fehlerbehandlung des Hosts übergehen. Die meisten MCP-Implementierungen für Einsteiger überspringen die Lifecycle-Logik und entdecken diese Lücke erst, wenn ein Serverprozess unerwartet beendet wird.
Eine weitere Client-Verantwortung wird häufig nicht erwähnt: In MCP kann der Server auch Anfragen an den Client senden. Das ist einer der Punkte, an denen sich MCP von einem einfachen REST-Mentalmodell unterscheidet. Die Capability-Aushandlung erfolgt bidirektional. Der Client muss so implementiert sein, dass er empfangen und nicht nur senden kann. Architektonisch führt das zu einer Komplexität, die REST-Entwickler beim ersten Lesen der Spezifikation nicht erwarten.
Wie Authentifizierung in die MCP-Verbindung passt
Die kurze Antwort: MCP übernimmt die Authentifizierung nicht für Sie. Das Basisprotokoll delegiert sie vollständig an die Transport- oder Anwendungsebene.
Diese Annahme verursacht die meisten Sicherheitslücken in MCP-Deployments. Teams lesen die MCP-Spezifikation, implementieren einen Server, verbinden einen Client und machen weiter – ohne tatsächlich Authentifizierung hinzuzufügen. Das Protokoll funktioniert problemlos. Der Server steht unbemerkt jedem Prozess offen, der ihn erreichen kann.
MCP sagt, dass Server Open Source sind und die Authentifizierung durch die Implementierung erfolgen muss, nicht durch das Protokoll selbst. Bei lokalen stdio-Verbindungen ist Authentifizierung oft nicht erforderlich, weil ohnehin nur lokale Prozesse den Server erreichen können. Bei entfernten MCP-Servern über HTTP bedeutet Authentifizierung typischerweise OAuth auf Transportebene oder API-Key-Validierung in der HTTP-Verarbeitung des Servers. Beides geschieht nicht automatisch. Beides erfordert eine explizite Implementierung.
Wenn Sie einen MCP-Server über HTTP bereitstellen und nicht explizit Authentifizierung integriert haben, behandeln Sie diesen Server als öffentlich, bis Sie dies nachgeholt haben.
Transportmechanismen: Wie MCP-Nachrichten tatsächlich übertragen werden
MCP spezifiziert das Nachrichtenformat – JSON-RPC über JSON –, schreibt jedoch nicht vor, wie diese Nachrichten zwischen Client und Server übertragen werden. Dafür ist die Transportebene zuständig. Es gibt zwei primäre Optionen, und die falsche für Ihr Setup zu wählen, gehört zu den häufigsten Fehlern bei der ersten Implementierung.
Die Wahl ist nicht willkürlich. Sie hängt davon ab, ob Client und Server auf derselben Maschine, im selben Netzwerk oder irgendwo über das Internet verteilt laufen. Sie hängt von Ihrer Proxy- und Load-Balancer-Konfiguration ab. Und sie hängt davon ab, wie viel Latenz Sie tolerieren können. Die meisten Anleitungen erwähnen den letzten Punkt nicht, weshalb Teams standardmäßig HTTP für alles verwenden und sich dann fragen, warum lokale Tool-Aufrufe langsam wirken.
MCP und seine JSON-RPC-Messaging-Ebene funktionieren unabhängig vom Transport auf dieselbe Weise. Ein Tool-Aufruf sieht im Nachrichtenformat identisch aus, egal ob er über stdin oder HTTP übertragen wird. Der Transport ist nur das Rohr. Was sich ändert, ist, welche Verbindungen verfügbar sind und was bei Fehlkonfigurationen ausfällt.
🤔 Moment.
Was passiert mit laufenden MCP-Anfragen, wenn die Transportverbindung mitten in einer Sitzung abbricht? Die meisten MCP-Übersichten beschreiben die Initialisierung und Tool-Aufrufe im Idealfall, doch eine Verbindungsunterbrechung während eines mehrstufigen Agentenlaufs ist ein reales Betriebsszenario. MCP selbst definiert keine Semantik für Wiederverbindungen – das ist Sache der Implementierung. Wenn Ihr MCP-Client Wiederverbindungen nicht explizit behandelt, führen unterbrochene Verbindungen zu stillen Fehlern: Das LLM erhält keine Tool-Ergebnisse mehr, der Host zeigt möglicherweise keinen Fehler an, und der Benutzer sieht eine hängende oder unvollständige Antwort ohne klares Signal zum Grund.
Stdio-Transport: Wann lokale Prozesskommunikation sinnvoll ist
Stdio ist der einfachere Weg. Der MCP-Client startet den Server als Subprozess und kommuniziert über stdin und stdout mithilfe von JSON-RPC-Nachrichten. Der Client schreibt in stdin des Servers. Der Server schreibt Antworten in stdout. Das ist die gesamte Transportebene.
Dieses Setup hat bei lokalen Tool-Aufrufen eine geringere Latenz als HTTP, weil kein Netzwerk-Stack beteiligt ist und außer der MCP-Initialisierung kein Handshake-Overhead entsteht. Es ist der Standard für Tools wie Claude Desktop und Cursor, bei denen der MCP-Server auf derselben Maschine wie die Host-Anwendung läuft.
Die praktische Einschränkung ist offensichtlich: stdio funktioniert nur, wenn Client und Server auf derselben Maschine laufen. Keine Ausnahmen. Wenn Ihr MCP-Server von mehreren Hosts gemeinsam genutzt werden soll oder auf einer entfernten Maschine läuft, ist stdio keine Option. Damit lassen sich die meisten lokalen IDE- und Desktop-Assistenten-Szenarien sauber abdecken – genau dafür wurde es entwickelt.
HTTP-plus-SSE-Transport: Was er hinzufügt und wo er scheitert
HTTP mit SSE (Server-Sent Events) ist der Transport für entfernte Verbindungen. Der Server stellt einen HTTP-Endpunkt bereit. Der Client öffnet einen SSE-Stream für Nachrichten vom Server zum Client. HTTP-POST-Anfragen übernehmen die Aufrufe vom Client zum Server. Die Kombination ermöglicht bidirektionale Kommunikation über eine Standard-HTTP-Infrastruktur – genau das, was Sie für jeden MCP-Server benötigen, der nicht lokal läuft.
Die neuere Variante „Streamable HTTP“ bündelt Teile davon, doch das Grundmuster bleibt: eine Richtung über SSE, die andere über POST.
Die eigentliche Reibung entsteht durch die SSE-Unterstützung. SSE wird nicht von allen Proxys, Load Balancern und API-Gateways korrekt verarbeitet. Einige beenden langlebige Verbindungen. Andere puffern Antworten und zerstören damit die Streaming-Semantik, die SSE erfordert. In Produktionsumgebungen mit Nginx, AWS API Gateway oder Unternehmens-Proxys in der Kette führt dies zu stillen Fehlern: Die SSE-Verbindung des Clients bricht ab, die Nachrichtenwarteschlange vom Server zum Client läuft auf, und in den Anwendungsprotokollen zeigt nichts an, warum. Sie sehen auf LLM-Seite einen hängenden Tool-Aufruf und auf Infrastrukturseite keinen offensichtlichen Grund.
Wenn Ihr HTTP+SSE-MCP-Server lokal funktioniert und in der Staging-Umgebung ausfällt, prüfen Sie die Proxy- und Load-Balancer-Konfiguration, bevor Sie die MCP-Implementierung selbst debuggen. Das löst die meisten dieser Fälle schneller als alles andere.
Wie der MCP-Lifecycle in der Praxis aussieht
Die MCP-Spezifikation als statisches Dokument zu lesen, übersieht etwas Wichtiges: MCP beschreibt eine aktive Sitzung mit einer definierten Abfolge von Schritten. Zwei Systeme müssen einen Handshake durchführen, verhandeln und ein gemeinsames Verständnis herstellen, bevor ein Tool aufgerufen wird. Diese Abfolge zu verstehen, unterscheidet „Ich habe über MCP gelesen“ von „Ich kann mit MCP entwickeln“.
Der Workflow von der ersten Verbindung bis zum ersten Tool-Ergebnis besteht aus drei tatsächlichen Phasen: Initialisierung und Capability-Aushandlung, dann der eigentliche Tool-Aufruf – oder das Lesen einer Ressource oder Abrufen eines Prompts – und anschließend die Antwortverarbeitung. Auf MCP aufbauende KI-Systeme sind darauf angewiesen, dass diese Sequenz korrekt abläuft. Wenn die Capability-Aushandlung eine Abweichung ergibt, wird der Tool-Aufruf nie versucht. Wenn der Tool-Aufruf ein fehlerhaftes Params-Objekt liefert, lehnt der Server ihn ab, bevor Geschäftslogik ausgeführt wird. Kontextbewusste KI-Anwendungen benötigen alle drei Phasen in sauberer Ausführung.
Capability-Aushandlung während der Initialisierung
Wenn sich ein MCP-Client nach Aufbau der Transportverbindung erstmals mit einem Server verbindet, tauschen beide Seiten einen Handshake aus. Der Client sendet eine initialize-Anfrage, die die von ihm unterstützte Protokollversion und seine eigenen Capabilities enthält. Der Server antwortet mit der von ihm unterstützten Protokollversion und seinen Capabilities. Stimmen die Versionen überein – oder wird eine akzeptable ausgehandelte Version vereinbart –, wird die Sitzung fortgesetzt. Andernfalls tritt die Abweichung hier zutage – nicht mitten im Workflow, nicht innerhalb eines Tool-Aufrufs, sondern direkt bei der Initialisierung.
Das ist tatsächlich nützlich. Dass Versionsabweichungen beim Handshake statt während der Ausführung sichtbar werden, bedeutet, dass Sie sofort erkennen, wenn ein Server eine veraltete Protokollversion ausführt, die Ihr Client nicht unterstützt. Die initialize-Antwort enthält zudem die Kennung für die Tools, Ressourcen und Prompts, die der Server bereitstellt. Der Client baut anhand dieser Antwort sein Verständnis der Server-Capabilities auf, bevor er überhaupt einen Tool-Aufruf sendet.
Wenn Sie die Initialisierungssequenz falsch umsetzen, schlägt alles danach still oder mit verwirrenden Fehlern fehl. Das ist das Erste, was ich prüfe, wenn mir jemand sagt, seine MCP-Integration „funktioniere nicht“.
Wie ein Tool-Aufruf durch das Protokoll läuft
Nach erfolgreicher Initialisierung ist ein Tool-Aufruf ein einzelner JSON-RPC-Request-/Response-Zyklus. Der Client sendet eine Anfrage mit einem Methodennamen, der dem Tool entspricht, einer eindeutigen Request-ID und einem Params-Objekt, das gemäß der JSON-Schema-Deklaration des Tools aufgebaut ist. Der Server validiert die Params gegen das Schema, führt das Tool aus und gibt ein strukturiertes JSON-Ergebnis mit derselben Request-ID zurück.
Der Schritt der Params-Validierung ist entscheidend. Ein fehlerhaftes Params-Objekt – ein fehlendes Pflichtfeld, ein falscher Typ oder ein unerwarteter Schlüssel, den das Schema nicht definiert – führt zu einem JSON-RPC-Fehler, bevor Geschäftslogik ausgeführt wird. Aus Sicht des Servers ist das korrektes Verhalten. Aus Sicht des LLM erzeugt der Empfang eines Fehlercodes anstelle zusätzlichen Kontexts Verwirrung, die später als halluzinierte oder unvollständige Antworten sichtbar wird.
Genau dieses Szenario stammt aus der Engineering-Arbeit von Latenode: Wenn Entwickler MCP-Server mit internen Systemen verbinden und auf undurchsichtige JSON-RPC-Validierungsfehler stoßen, liegt das Problem meist in einer Schema-Abweichung – der KI-Agent erstellt ein Params-Objekt, das nicht mit der Server-Deklaration übereinstimmt. In einem Latenode-Workflow kann ein JavaScript-Node die Parametergestaltung inline übernehmen, bevor die Anfrage den Server erreicht, während integriertes RAG einem KI-Node ermöglicht, die offizielle MCP-Spezifikation zu lesen und die Payload-Struktur zu validieren. Die Korrektur erfolgt auf Canvas-Ebene statt in einem Stack Trace um 23 Uhr. Es gelten Standardfehlercodes: -32600 steht für eine ungültige Anfrage, -32601 für eine nicht gefundene Methode und -32602 für ungültige Params. Diese drei decken die Mehrheit der Tool-Aufruffehler ab.
Sicherheitsaspekte, die die meisten MCP-Setups falsch umsetzen
Sicherheit in MCP betrifft nicht die Frage, ob das Protokoll selbst sicher ist. Das Protokoll ist klar spezifiziert und die JSON-RPC-Ebene gut verstanden. Die Risiken entstehen dadurch, wie Tool-Bereitstellungen konfiguriert sind, worauf diese Tools zugreifen können und was passiert, wenn eine kompromittierte oder bösartige Komponente in die Sitzung gelangt.
Prompt Injection über Tool-Antworten
Ein LLM, das ein MCP-Tool aufruft, vertraut der Tool-Antwort als zusätzlichem Kontext. Wenn sich irgendwo in der Pipeline eine nicht vertrauenswürdige Datenquelle befindet – ein Websuchergebnis, eine vom Benutzer hochgeladene Datei oder eine Drittanbieter-API –, kann eine bösartige Antwort Anweisungen einschleusen, die das Verhalten des LLM umleiten. Die Gegenmaßnahme sind Output-Sanitization auf Tool-Ebene und eine klare Trennung zwischen vertrauenswürdigen System-Prompts und von Tools zurückgegebenen Daten. Behandeln Sie Tool-Antworten als nicht vertrauenswürdige Eingaben, nicht als privilegierten Kontext.
Zu weitreichende Tool-Bereitstellung auf dem Server
Ein MCP-Server, der standardmäßig jede verfügbare Funktion bereitstellt, gibt dem Endbenutzer – und dem LLM – Zugriff auf alles, was der Server erreichen kann. Die meisten Teams stellen bereit, was bequem ist, nicht was notwendig ist. Das Prinzip der minimalen Tool-Bereitstellung gilt: Jedes registrierte Tool sollte einen definierten Umfang haben, und Tools mit Zugriff auf sensible Systeme sollten expliziten Kontext erfordern, bevor sie aufrufbar sind. Sandboxing auf Tool-Ebene – also die Einschränkung dessen, was ein bestimmtes Tool lesen, schreiben oder ausführen kann – ist in der Produktion nicht optional.
Fehlende Authentifizierung bei entfernten MCP-Servern
Wie im Abschnitt zum Transport erläutert: MCP über HTTP ohne Authentifizierungsebene ist ein offener Server. APIs, auf die über diese Tools zugegriffen wird, sind dann für jeden erreichbar, der den Endpunkt erreichen kann. Fordern Sie Authentifizierung auf Transport- oder Anwendungsebene, bevor irgendein MCP-Server über die lokale Entwicklung hinausgeht. OAuth oder API-Key-Validierung über HTTP+SSE sind beide sinnvoll. Keines davon geschieht automatisch.
Fehlende Verschlüsselung auf Transportebene für HTTP+SSE
SSE über einfaches HTTP bedeutet, dass alle MCP-Nachrichten – einschließlich Tool-Aufrufen, von Ressourcen zurückgegebenen Daten und sämtlichen Sitzungsmetadaten – im Klartext übertragen werden. In LAN-Umgebungen kann dies akzeptabel sein. In jeder Umgebung mit externem Datenverkehr ist TLS erforderlich. Die MCP-Spezifikation erzwingt dies nicht. Ihre Infrastruktur muss es tun.
Tool Poisoning durch einen kompromittierten Server
Dies ist das Bedrohungsmodell, über das die meisten Teams erst nach einem Sicherheitsvorfall nachdenken. Wenn einer der in einer Sitzung registrierten MCP-Server kompromittiert wird, kann das LLM seine Antworten nicht von legitimen Antworten unterscheiden. Ein manipulierter Server kann Anweisungen in Tool-Antworten einschleusen, die das Verhalten des LLM über die gesamte Sitzung hinweg beeinflussen – nicht nur bei Aufrufen dieses Servers. Jeder registrierte MCP-Server ist Teil der Vertrauensfläche des LLM. Die Frage lautet nicht: „Ist dieses Tool sicher?“ Sie lautet: „Sind alle registrierten Server sicher?“
💡 Der kontraintuitive Teil:
Die Vertrauensfläche von MCP wird nicht durch die Tools begrenzt, die der Benutzer bewusst aufruft – sie erstreckt sich auf jeden in der Sitzung registrierten Server. Ein Benutzer, der einen Tool-Aufruf auslöst, vertraut implizit den Berechtigungen und Ausgaben aller verbundenen MCP-Server, einschließlich solcher, mit denen er nie direkt interagiert hat. Das verändert die Sicht auf MCP-Sicherheit vollständig: Es geht nicht darum, „ob dieses Protokoll sicher ist“, sondern darum, „ob ich jeden Server geprüft habe, den diese Sitzung erreichen kann“. Die meisten Teams haben das nicht.
MCP in der Praxis: Reale Ökosysteme und wohin die Entwicklung geht
Die Spezifikation wird wichtiger, wenn Sie sehen, was darauf aufgebaut wird. GitHub verfügt inzwischen über MCP-Server für Repository-Operationen. Docker hat MCP-Tooling veröffentlicht. Das Ökosystem von OpenAI beginnt, sich mit dem Standard zu überschneiden. TypeScript- und Python-SDKs existieren und werden vom MCP-Projekt aktiv gepflegt. Entwickler, die früher für jedes KI-Modell einen eigenen Connector geschrieben hätten, können nun einen MCP-Server schreiben und ihn jedem konformen Host bereitstellen.
Das ist der praktische Test dafür, ob eine Spezifikation das NxM-Problem tatsächlich gelöst hat: Werden Implementierungen über Modellanbieter und Hosts hinweg wiederverwendet, oder schreiben Teams weiterhin für jede Kombination eigenen Code? Die Hinweise aus frühen Enterprise-Deployments – so ungenau die 28-%-Zahl aus der Analyse von Synvestable auch sein mag – deuten darauf hin, dass Wiederverwendung in relevantem Umfang stattfindet. Das bedeutet, dass die Spezifikation ihre Aufgabe erfüllt.
Für Teams, die mit Latenode entwickeln, ermöglicht der MCP Server Builder, einen Latenode-Workflow als MCP-Server bereitzustellen – aufrufbar aus Claude Desktop, Cursor oder jedem anderen MCP-kompatiblen Host. Die Workflows hinter diesem Server können Daten aus mehr als 5.500 Integrationen abrufen, KI mithilfe von integriertem RAG auf hochgeladene Dokumente anwenden oder benutzerdefinierte Logik in einem JavaScript-Node ausführen. Die Protokolldetails bleiben für jeden unsichtbar, der das Tool aufruft. Aus Sicht des Aufrufers ist es einfach ein Tool, das während der Capability-Aushandlung erkannt wurde. Aus Ihrer Sicht ist es ein vollständiger Automatisierungs-Workflow.
Die MCP-Spezifikation definiert die Schnittstelle. Was Sie auf der anderen Seite dieser Schnittstelle bereitstellen, liegt bei Ihnen.
Wenn Sie etwas entwickeln, das auch bei Problemen weiterlaufen muss: Implementieren Sie zuerst die Lifecycle-Behandlung, nicht die Tools. Fügen Sie Logging auf Transportebene hinzu. Validieren Sie Ihre JSON-Schema-Deklarationen mit echten Test-Payloads, bevor Sie ein LLM verbinden. Und denken Sie daran, dass jeder MCP-Server, den Sie registrieren, ab Abschluss des Handshakes Teil Ihrer Vertrauensfläche ist.
Das Protokoll ist sauber. Der schwierige Teil ist, wie so oft, alles drum herum.
