MCP erklärt: Was es verbindet, was es nicht tut und wo es passt

Das Model Context Protocol (MCP) ist ein offenes Protokoll, um KI-Anwendungen über standardisierte Client-Server-Verträge mit externen Fähigkeiten und Informationen zu verbinden. Ein MCP-Server kann Tools, Ressourcen und Prompts bereitstellen; ein MCP-kompatibler Host oder Client entdeckt und nutzt diese Fähigkeiten im Auftrag einer KI-Anwendung. MCP erfordert nicht, dass der Server sein eigenes Sprachmodell ausführt, und es ersetzt nicht die Agent-Runtime, die geschäftliche Autorisierung, die Mandantentrennung, die Anwendungs-APIs oder die Domänenarchitektur hinter den bereitgestellten Fähigkeiten.

Was MCP wirklich standardisiert

Vor MCP konnte jede KI-Anwendung externe Systeme über ihr eigenes Tool-Schema, Plugin-Format, ihre eigene Authentifizierungskonvention und ihren eigenen Verbindungscode integrieren. Derselbe Dienst konnte für einen Desktop-KI-Client, einen IDE-Agenten und eine benutzerdefinierte Anwendung unterschiedliche Adapter benötigen.

MCP schafft eine wiederverwendbare Protokollgrenze. Das externe System stellt Fähigkeiten über einen MCP-Server bereit, während kompatible KI-Hosts einen MCP-Client implementieren. Dies reduziert die Integrationskopplung zwischen der KI-Anwendung und dem zugrunde liegenden Tool- oder Datenanbieter.

Das Protokoll standardisiert nicht die gesamte Anwendung. Es standardisiert, wie Fähigkeiten über diese Grenze hinweg beschrieben, entdeckt und aufgerufen werden.

Das einfachste Beispiel

Angenommen, eine KI-Programmieranwendung benötigt Zugriff auf ein lokales Projektverzeichnis. Ohne MCP könnte die Anwendung ihre eigene Dateisystemintegration direkt implementieren.

Mit MCP kann ein Dateisystem-Server Fähigkeiten wie das Auflisten von Verzeichnissen, das Lesen genehmigter Dateien oder das Schreiben innerhalb eines erlaubten Arbeitsbereichs bereitstellen. Der KI-Host verbindet sich über einen MCP-Client und präsentiert diese Fähigkeiten dem Modell oder der Agent-Runtime.

Der Server muss die natürlichsprachliche Anfrage des Benutzers nicht verstehen. Der Host/das Modell entscheidet, welche Fähigkeit nützlich ist; der MCP-Server führt die strukturierte Anfrage unter seinen eigenen Sicherheitsregeln aus.

Wo das einfache Beispiel endet

MCP definiert nicht, wie der Host ein Tool auswählt, wie ein Agent plant, wie ein Geschäftsworkflow modelliert wird oder wie sich ein Domänenobjekt wie eine Rechnung oder ein Deployment verhalten soll.

Ein Protokoll kann die Integration interoperabel machen, während die zugrunde liegende Anwendung falsch, unsicher oder schlecht entworfen bleibt. Eine vollkommen gültige MCP-Anfrage kann dennoch die falsche geschäftliche Fähigkeit aufrufen.

Die zentrale Abgrenzung ist: MCP standardisiert Integrationssemantik, nicht Anwendungswahrheit oder geschäftliche Korrektheit.

Die MCP-Architektur: Host, Client und Server

Ein Host kann sich mit mehreren MCP-Servern verbinden, und ein MCP-Server kann einem oder mehreren zugrundeliegenden Systemen vorgelagert sein. Der Host bleibt dafür verantwortlich, MCP-Ergebnisse in die übergeordnete KI-Anwendung zu integrieren.

Der Server kann lokal beim Host laufen, als separater Prozess ausgeführt werden oder remote über einen Netzwerktransport erreichbar sein. Hosting-Topologie und Modellstandort sind unabhängige Entscheidungen.

Die drei zentralen Server-Primitive

Tools: aufrufbare Fähigkeiten

Tools sind strukturierte Operationen, die ein MCP-Server dem Host zur Verfügung stellt. Ein Tool hat einen Namen, eine Beschreibung und ein Eingabeschema; moderne Implementierungen können auch strukturierte Ausgaben bereitstellen.

Beispiele sind das Durchsuchen eines Repositorys, das Lesen eines Kundendatensatzes, das Erstellen eines Tickets, das Ausführen eines Builds oder das Senden einer Nachricht. Tools können schreibgeschützt sein oder Nebenwirkungen haben.

Eine gute MCP-Tool-Oberfläche sollte kohärente Benutzer- oder Agentenziele abbilden, anstatt jeden internen API-Endpunkt mechanisch zu spiegeln. Operationen mit unterschiedlichen Berechtigungen, Bestätigungsanforderungen oder Auswirkungsradius sollten in der Regel separate Tools sein.

Ressourcen: lesbarer Kontext und Daten

Ressourcen stellen Daten oder Inhalte bereit, die ein Client auflisten oder lesen kann. Sie passen natürlich, wenn die semantische Operation „Gib mir dieses Artefakt oder diese Information“ lautet statt „Führe diese Aktion aus“.

Eine Ressourcen-URI ist keine Autorisierungsgewährung. Der Server behält die Zugriffskontrolle und muss überprüfen, welcher Prinzipal das zugrundeliegende Objekt lesen darf.

Die Protokollrevision vom 2026-07-28 fügt Cache-Semantik für Listen- und Ressourcenleseantworten hinzu, einschließlich Aktualität und Cache-Geltungsbereich, wodurch das Caching-Verhalten expliziter wird.

Prompts: wiederverwendbare Vorlagen

MCP-Prompts ermöglichen es einem Server, wiederverwendbare Prompt-Vorlagen für kompatible Clients zu veröffentlichen. Dadurch können domänenspezifische Anweisungen näher beim Fähigkeitsanbieter bleiben.

Ein von einem MCP-Server bereitgestellter Prompt hat nicht automatisch Vorrang vor den System- oder Sicherheitsanweisungen des Hosts. Der Host entscheidet, wie Prompt-Material in seine Kontexthierarchie eingeht.

Vom Protokoll bereitgestellter Prompt-Inhalt sollte daher als Fähigkeitsdaten mit expliziter Vertrauenssemantik behandelt werden, nicht als uneingeschränkte Instruktionsautorität.

Tool oder Ressource?

Wo ist das KI-Modell?

MCP erfordert nicht, dass das Modell auf dem MCP-Server läuft. Das Modell kann in der Cloud gehostet, lokal gehostet, in die Desktop-Anwendung eingebettet oder über einen anderen Anbieter erreicht werden.

Der Host besitzt normalerweise die Modellinteraktion. Der MCP-Server stellt externe Fähigkeiten bereit. Ein lokaler MCP-Server kann daher von einem Host verwendet werden, dessen Modell in der Cloud läuft, und ein entfernter MCP-Server kann von einem Host verwendet werden, dessen Modell lokal läuft.

Wenn der MCP-Server selbst intern ein LLM aufruft, ist dieses Modell Teil der Server-Implementierung hinter der Protokollgrenze; es wird nicht von MCP erfordert.

MCP ersetzt keine APIs

Ein MCP-Server umhüllt oft bestehende APIs oder Dienste. REST, GraphQL, SQL, SDK-Aufrufe und interne Dienstverträge können genau dort bleiben, wo sie sind.

MCP fügt eine KI-orientierte Interoperabilitätsschicht hinzu. Die zugrunde liegende Domänen-API kann der maßgebliche Anwendungsvertrag für gewöhnliche deterministische Clients bleiben.

Die übliche Architektur ist daher API/Dienst zuerst, ausgewählte KI-orientierte Fähigkeit zweitens — nicht „jede API durch MCP ersetzen“.

MCP vs. Function Calling

OpenAI stellt derzeit entfernte MCP-Server als einen Tool-Typ neben gewöhnlichem Function Calling, Websuche, Shell und anderen Tools bereit. Diese Implementierung veranschaulicht die architektonische Beziehung: MCP-Konnektivität und die eigene Tool-Aufruf-Schnittstelle des Modells können kombiniert werden.

MCP erzeugt nicht die Agent-Schleife

Ein KI-Agent benötigt eine Laufzeitumgebung, die entscheiden, Tools aufrufen, Ergebnisse beobachten, Zustand aktualisieren und fortfahren oder stoppen kann. MCP kann einige der Tools und Daten bereitstellen, die von dieser Schleife verwendet werden.

Der MCP-Server wird nicht automatisch zum Planer, Gedächtnissystem oder Orchestrator. Diese Verantwortlichkeiten bleiben normalerweise im Host oder in der Agent-Laufzeitumgebung.

Eine nicht-agentische Anwendung kann ebenfalls MCP verwenden. Ein deterministischer MCP-Tool-Aufruf erfordert keinen autonomen mehrstufigen Agenten.

MCP vs. A2A

MCP verbindet in erster Linie einen KI-Host oder Agenten mit Fähigkeiten wie Tools, Ressourcen und Daten. A2A zielt auf die Zusammenarbeit zwischen unabhängigen Agentensystemen ab.

Ein Remote-Agent kann intern MCP nutzen, um auf Datenbanken und Tools zuzugreifen, während er anderen Agenten eine A2A-Schnittstelle bereitstellt. Die Protokolle können daher geschichtet statt ersetzt werden.

Der bestehende Artikel zum Protokoll-Stack behandelt den breiteren Vergleich von MCP/A2A/UCP/AP2/A2UI; G02 bleibt die kanonische MCP-Definition.

Lokale und entfernte MCP-Nutzung haben unterschiedliche Transportrealitäten

MCP kann sich mit lokalen und entfernten Servern verbinden. Lokale Desktop-Integrationen verwenden üblicherweise Transporte auf Prozessebene wie stdio; entfernte Server verwenden HTTP-orientierten Transport.

Die Revision vom 28.07.2026 macht den Protokollkern zustandslos. Anfragen tragen die für die Protokollverarbeitung erforderlichen Informationen, anstatt vom früheren sitzungsorientierten Modell auf Protokollebene abzuhängen.

Die aktuelle Revision platziert außerdem Methoden- und Fähigkeitsnamen in HTTP-Headern, damit Gateways, WAFs, Rate-Limiter und Load-Balancer MCP-Datenverkehr natürlicher routen und messen können.

Warum MCP-Versionsbewusstsein wichtig ist

SDK-Version und Protokollversion sind ebenfalls unterschiedliche Dinge. Das aktuelle TypeScript v2 SDK ist die stabile Linie für die Revision vom 28.07.2026, während ältere v1.x eine Wartungslinie für das Verhalten der 2025-Ära bleibt.

Architekturdokumentation sollte sowohl die SDK-/Bibliotheksversion als auch die Protokollrevision erfassen, wenn Interoperabilitätsverhalten davon abhängt.

Was sich in MCP 2026-07-28 geändert hat

Roots, Sampling und Logging sind nicht mehr die Richtung für neue Implementierungen

Die Veröffentlichung vom 28.07.2026 kennzeichnet Roots, Sampling und Logging als veraltete Protokollfähigkeiten mit einem definierten Kompatibilitätsfenster.

Ältere Tutorials zeigen diese Funktionen möglicherweise noch als zentrale Primitive. Neue Implementierungsarbeiten sollten der aktuellen Spezifikation folgen, anstatt ältere Lebenszyklusdiagramme blind zu kopieren.

Veraltung bedeutet nicht sofortige Entfernung. Es bedeutet, dass neue Systeme unnötige neue Abhängigkeiten von Fähigkeiten vermeiden sollten, von denen sich das Protokoll entfernt.

Lang laufende Arbeit ist nicht dasselbe wie ein gewöhnlicher MCP-Tool-Aufruf

Lang laufende Operationen benötigen Lebenszyklus-Semantik, die über ein einfaches sofortiges Tool-Ergebnis hinausgeht. Im aktuellen Ökosystem wurden Tasks in eine dedizierte MCP-Erweiterung verschoben.

Dies bekräftigt ein nützliches Designprinzip: Das Basisprotokoll muss nicht jedes Anliegen der Agenten-Laufzeit absorbieren.

Eine Anwendung kann die Verantwortung für lang laufende Workflows auch vollständig in ihrer eigenen Laufzeit behalten und gewöhnliche MCP-Tools als zugrunde liegende Operationen verwenden.

MCP Apps erweitern die UI-Fähigkeiten, ohne das Kernprotokoll neu zu definieren

MCP Apps verknüpfen reichhaltigere interaktive UI-Erlebnisse durch das Erweiterungsmodell mit MCP-Tools.

Der Host kontrolliert weiterhin, wie diese UI eingebettet, in einer Sandbox ausgeführt und abgesichert wird.

Der Austausch von Kernfähigkeiten und das UI-Rendering sollten daher getrennte Architekturverantwortlichkeiten bleiben.

MCP-Autorisierung ist nicht Ihr vollständiges Autorisierungsmodell

Remote-MCP benötigt Authentifizierungs- und Autorisierungsmechanismen auf Protokollebene, damit Clients und Server vertrauenswürdigen Zugriff herstellen können. Die aktuelle Spezifikation härtet weiterhin das Verhalten im Zusammenhang mit OAuth/OIDC.

Diese Schicht beantwortet, ob ein Client eine Verbindung herstellen oder Protokoll-Scopes anfordern darf. Sie beantwortet nicht automatisch, ob Alice Bestellung 123 erstatten darf, ob ein Agent Produktionskonfiguration schreiben darf oder ob Mandant A Daten von Mandant B lesen darf.

Diese Domänenentscheidungen gehören in das Autorisierungsmodell des Servers/der Anwendung und müssen durchgesetzt werden, bevor die zugrunde liegende Operation aufgerufen wird.

Identität kann mehrere Grenzen überschreiten

Eine MCP-Anfrage kann die MCP-Client-Anwendung, den angemeldeten Menschen, eine Agenten-/Sitzungsidentität und ein nachgelagertes Dienstkonto umfassen.

Der Server benötigt eine explizite Richtlinie, im Namen welches Prinzipals die Operation ausgeführt wird. Andernfalls kann eine leistungsstarke Dienstanmeldeinformation zu einem Confused-Deputy-Pfad werden.

Für den Unternehmenseinsatz ist die Korrelation zwischen Benutzeridentität, Agentenidentität, MCP-Verbindung und nachgelagerter Autorisierung ebenso wichtig wie die Protokollkompatibilität.

Mandantentrennung bleibt außerhalb der MCP-Fähigkeitserkennung

Ein mandantenfähiger MCP-Server muss den Mandantenbereich anwenden, wenn er mandanteneigene Ressourcen liest oder ändert. Die Rückgabe eines Tools namens search_documents definiert nicht, welche Dokumente welches Mandanten zulässig sind.

Der Mandantenbereich sollte aus einer vertrauenswürdigen Identität oder Mitgliedschaft abgeleitet und in Datenbanken, Caches, Vektorsuche, Objektspeicher und nachgelagerte APIs übernommen werden.

Das Abrufen mandantenübergreifender Inhalte und die Aufforderung an das Modell, sie nicht zu verwenden, ist bereits ein Isolationsfehler.

MCP definiert keine Single Source of Truth

Ein MCP-Server kann eine Datenbank, ein Dokumentenrepository, einen Web-Suchdienst oder eine KI-generierte Zusammenfassung bereitstellen. Das Protokoll erklärt nicht, welche Quelle für eine Aussage maßgeblich ist.

Regeln zur Single Source of Truth gehören zur Anwendungs-/Domänenarchitektur. Der Host oder Server kann Autorität durch Tool-Design, Metadaten, Zugriffsrichtlinien oder Validierung kodieren, aber MCP selbst macht eine Fähigkeit nicht „wahr“.

Ein Tool kann daher über MCP einwandfrei aufrufbar sein und dennoch veraltete, sekundäre oder nicht maßgebliche Informationen zurückgeben.

MCP und Kontext-Engineering

MCP kann die Fähigkeiten und Informationen erweitern, die einer KI-Anwendung zur Verfügung stehen, aber Kontext-Engineering bestimmt weiterhin, was das Modell erreicht.

Tool-Kataloge verbrauchen in vielen Hosts modellsichtbaren Kontext. Tool-Ergebnisse können groß sein. Ressourcen können zahlreich sein. Ein Host benötigt Auswahl, Filterung, dynamisches Laden und Komprimierung, anstatt bei jedem Turn alles offenzulegen.

Verfügbarkeit von Fähigkeiten und modellsichtbarer Kontext sollten daher als getrennte Schichten behandelt werden.

MCP-Tools um Ergebnisse und Risikogrenzen herum entwerfen

Genehmigungen gehören in die Ausführungsarchitektur

Ein Host kann vor dem Aufruf ausgewählter MCP-Tools eine Benutzergenehmigung verlangen. Die aktuelle MCP-Integration von OpenAI unterstützt automatische oder explizit genehmigende Ausführungsmuster.

Host-Genehmigung ist nützlich, sollte aber nicht der einzige Schutz des Servers sein, da ein anderer kompatibler MCP-Client ein anderes Genehmigungsmodell verwenden kann.

Für destruktive oder finanziell folgenreiche Aktionen verwenden Sie Defense in Depth: klarer Tool-Vertrag, Laufzeitgenehmigung wo angemessen, serverseitige Autorisierung, Geschäftsvalidierung und Audit.

MCP-Observability sollte Protokollaufrufe mit Domänenaktionen verbinden

Ein MCP-Trace ist am nützlichsten, wenn er mit dem zugrunde liegenden Anwendungsaufruf, der Datenbankänderung oder der Geschäftstransaktion korreliert werden kann.

Der Ökosystem-Standard vom 2026-07-28 standardisiert W3C Trace Context Propagation-Konventionen und erleichtert es, eine Anfrage über Host, Client, Server und nachgelagerte Dienste hinweg zu verfolgen.

Protokolllogs allein reichen für folgenreiche Operationen nicht aus. Audit-Nachweise sollten auch den relevanten Principal, Tenant, die Zielressource, die Genehmigung und die resultierende Zustandsänderung aufzeichnen.

Was MCP nicht beheben kann

Ursprünglicher Implementierungsnachweis: Aaasaasa AI Client

Die Anwendung kann einen authentifizierten Streamable HTTP MCP-Endpunkt auf Loopback ausführen. Der Endpunkt stellt nur Verzeichnisse bereit, die über den zentralen Workspace-Berechtigungsbroker ausgewählt wurden.

Der lokale Endpunkt und die Remote-Route sind getrennte Anliegen: Der lokale Connector kann nur an Loopback binden, während ein Secure MCP Tunnel den genehmigten MCP-Dienst für einen zulässigen externen AI-Client erreichbar machen kann, ohne den gesamten lokalen Rechner offenzulegen.

Das zentrale Berechtigungsmodell unterscheidet Profile für Nur-Chat, Nur-Lesen, Projekt-Schreiben und benutzerdefinierte Verzeichnisse. Direct Chat hat keinen Dateisystem- oder Shell-Zugriff; tool-fähige Agent-Laufzeiten verwenden das ausgewählte Berechtigungsprofil.

Dies ist eine direkte Implementierung der G02-Grenze: MCP bietet die standardisierte Fähigkeitsverbindung, während der anwendungseigene Berechtigungsbroker entscheidet, welche Verzeichnisse der Server bereitstellen darf.

Wann MCP gut passt

Wann Sie MCP nicht benötigen

Fügen Sie MCP nicht allein deshalb hinzu, weil die Anwendung KI verwendet. Wenn Ihr Backend bereits eine interne API aufruft und kein unabhängiger MCP-Client diese Fähigkeit benötigt, kann ein gewöhnlicher Funktions- oder Dienstaufruf klarer sein.

MCP schafft Mehrwert an einer Interoperabilitätsgrenze. Ohne diese Grenze kann das Protokoll zu einer unnötigen Adapterschicht werden.

Die architektonische Frage lautet nicht „Verwendet dieses Projekt KI?“, sondern „Profitieren unabhängig voneinander weiterentwickelte KI-Hosts und Fähigkeitsanbieter von einem Standardvertrag?“

MCP-Sicherheitscheckliste

Häufige Missverständnisse

Eine praktische MCP-Designsequenz

MCP-Architekturcheckliste

Randfälle und Einschränkungen

Ein lokaler stdio-MCP-Server kann wenig Netzwerkexposition haben und dennoch gefährlich sein, wenn der Prozess selbst übermäßige Dateisystem- oder Shell-Berechtigungen hat.

Ein entfernter MCP-Server kann nur öffentliche Dokumentation oder hochsensible Unternehmensaktionen bereitstellen. „Remote-MCP“ sagt ohne den Fähigkeits- und Autorisierungskontext wenig über das Risiko aus.

Einige Server verwenden möglicherweise nur Tools und ignorieren Ressourcen/Prompts. MCP-Kompatibilität erfordert nicht, dass jedes optionale Primitiv gleich wichtig ist.

Ein Host kann zwischen seinem eigenen internen Tool-Modell und MCP übersetzen. Benutzer sehen die Protokollgrenze möglicherweise nie direkt, was akzeptabel ist, wenn Sicherheit und Zuordnung klar bleiben.

MCP entwickelt sich weiterhin schnell. Erweiterungen, Autorisierungsmuster, SDK-APIs und Ökosystemkonventionen können sich schneller ändern als die zentrale architektonische Unterscheidung.

Was würde diese Antwort ändern?

Zukünftige MCP-Revisionen können Lebenszyklus, Transporte, Autorisierung und Erweiterungsmechanismen ändern. Die Revision vom Juli 2026 zeigt bereits, warum implementierungsspezifische Aussagen datiert werden müssen.

Die kanonische Grenze würde sich nur ändern, wenn MCP von einem Interoperabilitätsprotokoll zu einem End-to-End-Standard für Anwendungs-/Agentenarchitekturen erweitert würde. Das ist nicht das, was das aktuelle Protokoll definiert.

Überprüfen Sie für Implementierungsarbeiten immer die aktuelle Spezifikation und die genaue SDK-Version, anstatt versionssensible Beispiele aus älteren Tutorials zu kopieren.

Verwandtes kanonisches Wissen

MCP gehört stromabwärts von Agentic AI: Verstehen Sie zuerst die Grenze zwischen Agent, Laufzeit und Werkzeug und verwenden Sie dann MCP, wenn externe Fähigkeiten einen portablen Protokollvertrag benötigen.

MCP hängt auch von RBAC und Mandantenisolierung ab, da die Exposition von Fähigkeiten auf Protokollebene nicht die Anwendungsautorisierung bestimmt.

Der breitere Artikel zum Protokollstapel erklärt, wo MCP neben A2A, UCP, AP2 und A2UI steht. G02 bleibt die kanonische Quelle für MCP selbst.

Häufig gestellte Fragen

Glossar

Fazit

MCP ist am einfachsten zu verstehen, wenn seine Grenze eng bleibt: Es verbindet KI-Anwendungen über ein Standardprotokoll mit externen Fähigkeiten.

Das Modell muss nicht auf dem MCP-Server leben. Der Server wird nicht zur Agentenlaufzeit. Ein aufgeführtes Werkzeug wird nicht zu einer autorisierten Geschäftsaktion. Und MCP ersetzt nicht die zugrunde liegende API, die Source of Truth, die Mandantenisolierung oder die Domänenarchitektur.

Diese Enge ist die Stärke des Protokolls. MCP kann standardisieren, wie KI-Systeme auf Werkzeuge und Daten zugreifen, während es Anwendungseigentum, Sicherheit, Geschäftssemantik und Modellwahl in den Schichten belässt, die tatsächlich dafür verantwortlich sind.

Primärquellen und aktuelle Dokumentation

MCP entwickelt sich schnell weiter, daher sind versionssensible Aussagen in diesem Artikel an den Stand vom 8. Oktober 2026 gebunden. Der Abschnitt zum Aaasaasa AI Client ist ursprüngliche Implementierungsnachweise und ausdrücklich auf den verifizierten MCP-Connector- und Berechtigungsbroker-Umfang beschränkt.