Was ist MCP (Model Context Protocol)?
Das Model Context Protocol (MCP) ist ein offener Standard, den Anthropic im November 2024 veröffentlicht hat. Er gibt KI-Agenten eine einheitliche Möglichkeit, sich mit externen Werkzeugen und Datenquellen zu verbinden: Datenbanken, CRM-Systeme, APIs, Dateisysteme. Im Dezember 2025 übergab Anthropic das Protokoll an die Linux Foundation. Die Idee dahinter ist einfach: Statt jedes Mal eine individuelle Integration zu bauen, wenn Sie einen Agenten mit einem Werkzeug verbinden, erstellen Sie einen MCP-Server pro Datenquelle -- und jeder MCP-kompatible Agent kann ihn nutzen.
Ende 2025 gab es über 10.000 öffentliche MCP-Server und 97 Millionen monatliche SDK-Downloads. OpenAI, Google, Microsoft, AWS und Salesforce haben den Standard übernommen.
Wenn Ihnen "MCP" in der KI-Berichterstattung immer wieder begegnet und Sie eine klare Erklärung suchen, was es tatsächlich leistet -- einschließlich seiner Grenzen --, dann ist dieser Beitrag genau richtig.
Was ist MCP?#
Die Ein-Satz-Definition#
MCP ist ein offener Standard, der festlegt, wie KI-Agenten sich mit externen Werkzeugen, Datenquellen und Diensten verbinden -- damit Sie die Integration einmal bauen und jeder MCP-kompatible Agent sie nutzen kann.
Warum es entwickelt wurde: das N-x-M-Integrationsproblem#
Vor MCP war jede Verbindung zwischen KI-Agent und Werkzeug ein eigenständiges Entwicklungsprojekt. Neuen Agenten gebaut? Neue Konnektoren für jedes Werkzeug schreiben. KI-Anbieter gewechselt? Alle Integrationen neu schreiben. Intern beschrieb Anthropic dies als N-x-M-Problem: N Agenten multipliziert mit M Werkzeugen -- ein unübersichtliches Geflecht aus brüchigem, inkompatiblem Code.
Bei drei KI-Agenten und fünfzehn Werkzeugen sind das potenziell fünfundvierzig individuelle Integrationen, die gebaut und gewartet werden müssen. Sobald sich die API eines Werkzeugs ändert oder Sie das zugrundeliegende Modell wechseln möchten, geht etwas kaputt -- auf schwer vorhersehbare und kostspielig zu behebende Weise.
MCP reduziert das auf N+M. Ein Server pro Werkzeug, ein Client pro Agent. Jeder MCP-kompatible Agent kann jeden MCP-kompatiblen Server ohne Mehraufwand erreichen. Aus fünfundvierzig individuellen Integrationen werden achtzehn standardisierte Verbindungen.
Die USB-C-Analogie: Was sie trifft und wo sie endet#
Der Vergleich, den Anthropic und die Branche am häufigsten heranziehen, ist USB-C: ein einziger Anschlussstandard, der jahrzehntelange proprietäre Kabel überflüssig gemacht hat. Ein USB-C-Kabel überträgt Strom, Daten und Video über einen einzigen Anschluss an jedem Gerät. MCP überträgt Kontext, Werkzeugaufrufe und Prompts über ein einziges Protokoll zwischen jedem KI-Agenten und jedem verbundenen System.
Wo die Analogie an ihre Grenzen stößt: USB-C ist physische Hardware. Ein Kabel erfüllt die Spezifikation -- oder eben nicht. Ein MCP-Server kann zwar technisch protokollkonform sein und trotzdem Authentifizierungslücken, instabile Schemata oder Sicherheitsschwachstellen aufweisen. Der Standard ermöglicht die Verbindung. Er garantiert nichts über das, was darüber läuft.
Wie MCP funktioniert#
Drei Rollen: Host, Client und Server#
MCP verteilt die Verantwortung auf drei Rollen. Der Host ist die KI-Anwendung -- Claude Desktop, ein benutzerdefinierter Agent, ein IDE-Plugin. Er verwaltet die Gesamtsitzung. Der Client lebt innerhalb des Hosts und übernimmt die eigentliche Kommunikation mit MCP-Servern: Er übersetzt die Anfragen des Modells in MCP-Aufrufe und gibt die Ergebnisse zurück. Der Server ist ein schlanker Prozess, der ein bestimmtes Werkzeug oder eine Datenquelle kapselt und für jeden MCP-kompatiblen Client zugänglich macht.
Beim Sitzungsstart verbindet sich der Client mit den konfigurierten Servern und fragt jeden, was er kann. Jeder Server antwortet mit seinen Fähigkeiten, und das Modell kann diese Fähigkeiten während der Konversation nutzen.
Drei Grundbausteine: Tools, Resources und Prompts#
Jeder MCP-Server stellt eine Kombination aus drei Bausteinen bereit:
| Grundbaustein | Funktion | Analogie |
|---|---|---|
| Tools | Funktionen, die der Agent aufrufen kann, um Aktionen auszuführen: in eine Datenbank schreiben, eine E-Mail senden, eine Abfrage ausführen | Ein REST API POST-Endpunkt |
| Resources | Nur-Lese-Daten, auf die der Agent zugreifen kann: Dateien, Datensätze, Dokumente | Ein REST API GET-Endpunkt |
| Prompts | Vordefinierte Vorlagen, die dem Modell strukturierten Kontext für häufige Aufgaben bereitstellen | Ein System-Prompt für einen bestimmten Workflow |
Die meisten Produktiv-Szenarien stützen sich vorrangig auf Tools. Resources und Prompts sind wertvoll, werden in aktuellen Deployments aber seltener eingesetzt.
Transportschicht: lokal (stdio) vs. remote (HTTP/SSE)#
MCP unterstützt zwei Transportmodi:
- stdio (Standard Input/Output): Der Server läuft als lokaler Prozess auf derselben Maschine wie der Client. Einfacher einzurichten, geeignet für Entwicklerwerkzeuge und lokale Agenten.
- HTTP mit Server-Sent Events (SSE): Der Server läuft remote. Der Client sendet Anfragen über HTTP; der Server streamt Antworten über SSE. Dies ist das Modell für Produktivumgebungen, in denen der Server für Agenten erreichbar sein muss, die in Cloud-Infrastruktur laufen.
Ein konkretes Beispiel: Ein KI-Agent ruft Salesforce-Daten ab#
Ein Vertriebsleiter bittet seinen KI-Assistenten: "Hole die Geschäftsdaten des letzten Quartals aus Salesforce und fasse zusammen, wo jedes Geschäft ins Stocken geraten ist."
Mit MCP: Der Agent ruft einen MCP-Server auf, der Ihre Salesforce-Instanz kapselt. Der Server fragt die relevanten Datensätze ab und liefert strukturierte Daten zurück -- keine Salesforce-Zugangsdaten im Code des Agenten, kein individueller API-Wrapper und ein vollständiger Audit-Trail jedes Werkzeugaufrufs.
Ohne MCP: Entweder hat der Agent überhaupt keinen Zugriff auf Salesforce, oder jemand hat eine proprietäre Integration gebaut, die bricht, sobald Salesforce seine API aktualisiert oder das Team den KI-Anbieter wechselt.
Das MCP-Ökosystem heute#
Von 100 Servern beim Start auf über 17.000 indexierte Ende 2025#
MCP startete im November 2024 mit rund 100 Servern, die von Anthropic und frühen Partnern gebaut wurden. Bis Ende 2025 war das Ökosystem auf über 10.000 produktionsreife Server angewachsen, die von großen Registries erfasst werden, während breitere Indexe über 17.000 Einträge über alle Qualitätsstufen hinweg auflisten (Glama, Dezember 2025).
97 Millionen monatliche SDK-Downloads über Python und TypeScript#
Die Python- und TypeScript-SDKs überschritten im Dezember 2025 zusammen 97 Millionen monatliche Downloads (Anthropic / Linux Foundation-Ankündigung, Dezember 2025). Von nahezu null auf neunstellige monatliche Downloadzahlen in weniger als 14 Monaten -- das ist schneller, als die meisten Entwicklerinfrastruktur-Standards in diesem Stadium erreichen.
Wer MCP übernommen hat: OpenAI, Google, Microsoft, AWS, Salesforce und mehr#
OpenAI übernahm MCP im März 2025 und integrierte es in alle ChatGPT-Produkte. Google, Microsoft Azure, AWS und Salesforce folgten und machten MCP zur Standard-Integrationsschicht für Agenten auf den großen Cloud-Plattformen. Entwicklerwerkzeug-Unternehmen wie Zed, Replit und Sourcegraph bauten MCP-Unterstützung in ihre KI-gestützten Coding-Funktionen ein.
Ein MCP-Server, den Sie heute bauen, kann von jedem KI-Agenten auf jeder dieser Plattformen ohne Änderungen genutzt werden.
Die Übergabe an die Linux Foundation: Was herstellerneutrale Governance in der Praxis bedeutet#
Im Dezember 2025 übergab Anthropic MCP an die Linux Foundation, wo es zum Gründungsprojekt der Agentic AI Foundation (AAIF) wurde -- einem zweckgebundenen Fonds, den Anthropic, Block und OpenAI gemeinsam ins Leben riefen.
Herstellerneutrale Governance ist hier entscheidend. Wenn ein Standard bei einer offenen Stiftung liegt statt bei einem einzelnen Unternehmen, kann kein Anbieter die Spezifikation zu seinem eigenen Vorteil ändern. Unternehmenskunden können darauf aufbauen, ohne befürchten zu müssen, dass eine Geschäftsentscheidung bei Anthropic ihre Investition entwertet. Es ist dasselbe Modell, das Linux, Kubernetes und OpenTelemetry zu sicheren Infrastrukturentscheidungen gemacht hat.
Warum MCP für KI-Agenten wichtig ist#
Der Engpass ist der Kontext, nicht die Schlussfolgerungsfähigkeit#
Der limitierende Faktor für die meisten KI-Agenten ist nicht die Schlussfolgerungsfähigkeit. Es ist der Kontext. Ein Modell, das Ihre CRM-Daten oder Kundenhistorie nicht einsehen kann, kann keine nützlichen Antworten darüber geben -- nur Vermutungen.
MCP adressiert genau diese Lücke. Ein Agent, der mit den richtigen MCP-Servern verbunden ist, kann Live-Daten abfragen, bevor er antwortet, statt sich auf Trainingswissen zu verlassen. Er kann Aktionen in echten Geschäftssystemen ausführen und Daten aus mehreren Quellen in einer einzigen Interaktion kombinieren. Das funktioniert konsistent, unabhängig davon, welches Modell die Schlussfolgerung übernimmt.
Was Agenten mit Werkzeugzugriff können -- und was ohne#
Ohne Werkzeugzugriff ist ein KI-Agent ein ausgefeilter Textprozessor. Er kann über Informationen nachdenken, die man ihm gegeben hat, aber er kann keine neuen Informationen beschaffen und keine Aktionen ausführen.
Mit Werkzeugzugriff über MCP wird derselbe Agent zu einem Teilnehmer in Ihren Systemen. Er kann prüfen, ob ein Terminslot verfügbar ist, bevor er ihn anbietet, die Historie eines Kunden vor einem Gespräch abrufen, eine Police nachschlagen, bevor er eine Deckungsfrage beantwortet, und seine Ergebnisse zurück ins führende System schreiben. Der Unterschied zwischen einem Demo-Agenten und einem Produktiv-Agenten liegt meist in der Datenanbindung -- nicht im Modell.
Weniger Halluzinationen, fundiertere Antworten#
Wenn ein Agent Live-Daten über MCP-Tools abruft, statt sich auf Trainingswissen oder ein statisches Kontextfenster zu verlassen, spiegeln seine Antworten die Realität wider. Der Terminslot, den er anbietet, existiert tatsächlich. Die Police, die er zitiert, ist die aktuelle. Der Kontostand des Kunden stammt aus den heutigen Datensätzen -- nicht aus etwas, das aus dem Training interpoliert wurde.
Halluzinationen treten am häufigsten auf, wenn Modelle Faktenaussagen aus dem Gedächtnis generieren. Am seltensten treten sie auf, wenn Modelle über gerade abgerufene Daten schlussfolgern. MCP verschiebt Agenten in Richtung Letzteres.
Demo-Agenten vs. Produktiv-Agenten#
Die meisten Agenten-Demos wirken überzeugend, weil sie in einer kontrollierten Umgebung mit maßgeschneidertem Kontext laufen. Was in der Produktion scheitert, ist meist nicht das Modell: Der Agent kann das benötigte System nicht erreichen, bekommt veraltete oder unvollständige Daten oder hat keinen strukturierten Weg, auf das Gelernte zu reagieren.
MCP beseitigt diese Integrationsarbeit nicht. Es standardisiert sie. Teams, die produktive MCP-Integrationen gebaut haben, berichten, dass das Protokoll selbst nicht der schwierige Teil ist -- Authentifizierung, Schema-Management und Sicherheitshärtung sind die eigentlichen Komplexitätstreiber. Doch ohne einen Standard wie MCP erfordert selbst der Weg zu diesen schwierigeren Problemen zunächst den Bau von proprietärem Verbindungscode.
Was MCP nicht löst#
Klar zu benennen, wo die Grenzen liegen, ist ebenso nützlich wie zu erklären, was es leistet.
Authentifizierung und Zugriffskontrolle bleiben Ihre Aufgabe#
MCP definiert nicht, wie Ihr Server Clients authentifiziert oder Anmeldedaten für den zugrunde liegenden Dienst verwaltet, den er kapselt. Sie müssen weiterhin eine Authentifizierungsschicht aufbauen oder integrieren -- OAuth2, API-Keys, Token-Scoping -- und diese korrekt umsetzen. In Produktivprojekten bringt die Authentifizierung häufig vier bis sechs Wochen Mehraufwand mit sich, den Teams ursprünglich nicht eingeplant hatten (Intuz / Zeo, 2025-2026).
Sicherheit: Prompt Injection, zu weit gefasste Werkzeugberechtigungen und Lookalike-Tools#
Forschungsarbeiten aus dem Jahr 2025 identifizierten aktive Produktionsrisiken in MCP-Deployments: Prompt Injection (bei der eine bösartige Eingabe einen Agenten dazu bringt, destruktive Werkzeuge aufzurufen), zu weit gefasste Werkzeugberechtigungen (Agenten mit mehr Zugriff als nötig) und Lookalike-Tool-Angriffe (ein kompromittierter MCP-Server, der einen vertrauenswürdigen imitiert) (Zuplo MCP Security Report / Astrix State of MCP Server Security, 2025). Das Protokoll schützt standardmäßig gegen keines dieser Risiken. Gehärtete Produktionsserver erfordern eine explizite Sicherheitsarchitektur.
Schema-Drift bei Änderungen der zugrunde liegenden Systeme#
Wenn sich das System ändert, das Ihr MCP-Server kapselt -- ein CRM, das seine API aktualisiert, ein Datenbankschema, das sich verschiebt --, bricht der Server. Ein MCP-Server, der unerwartete Datentypen zurückgibt, verursacht harte Fehler in nachgelagerten Agenten. Eine manuell geschriebene Integration könnte sich graceful degradieren; MCP-Server tun das in der Regel nicht. Sie brauchen eine Versionierungsstrategie, bevor Sie das in der Produktion erleben.
Die Qualität variiert stark im gesamten Ökosystem#
Unter den Tausenden öffentlich verfügbarer MCP-Server reicht die Qualität von produktionsreif bis zu kaum funktionalen Demos. Viele wurden gebaut, um ein Konzept zu demonstrieren -- nicht um reale Last, Grenzfälle oder Fehlerzustände zu bewältigen. Einen Server von der Stange zu verwenden, ohne zu verstehen, was man ausführt, ist ein Risiko -- insbesondere bei Servern, die auf sensible Systeme zugreifen.
Brauchen Sie einen individuellen MCP-Server?#
Wann ein fertiger Server ausreicht#
Wenn Sie weitverbreitete SaaS-Tools integrieren -- GitHub, Slack, Google Drive, HubSpot -- und Ihre Anforderungen standard sind, gibt es gut gepflegte Community-Server, die aktiv in der Produktion eingesetzt werden. Kuratierte Registries wie Glama erfassen produktionsreife Server und sind ein sinnvoller Ausgangspunkt.
Wann Sie etwas Maßgeschneidertes brauchen#
Sie brauchen einen individuellen Server, wenn das System, das Sie anbinden möchten, proprietär ist: eine interne Datenbank, ein veraltetes EHR-System, eine maßgeschneiderte API Ihres Teams. Dasselbe gilt, wenn Ihre Compliance-Anforderungen (HIPAA, SOC 2, Finanzvorschriften) spezifische Zugriffskontrollen und Audit-Trails verlangen, die generische Server nicht bieten, oder wenn Ihre Integration Geschäftslogik erfordert, die ein fertiger Server nicht abbildet.
Hinzu kommt die Wartungsfrage. Einen Server, den Sie selbst gebaut haben und besitzen, können Sie aktualisieren, wenn sich das zugrunde liegende System ändert, und patchen, wenn ein Sicherheitsproblem auftaucht. Ein Community-Server liegt in der Wartungsverantwortung anderer.
Was ein produktionsreifer Server tatsächlich erfordert#
Ein produktionsreifer MCP-Server verfügt über ordnungsgemäße Authentifizierung und Zugriffskontrollen, explizite Einschränkungen des Werkzeugumfangs, Fehlerbehandlung, die graceful fehlschlägt und klar protokolliert, eine Versionierungsstrategie für Schema-Änderungen, eine Sicherheitsüberprüfung gegen bekannte Angriffsvektoren und dokumentierte Wartungsverantwortung.
Das ist keine hohe Hürde. Es ist eine Engineering-Hürde -- keine Prototyp-Hürde. Die meisten öffentlich gelisteten MCP-Server erfüllen sie nicht.
Für Teams, die produktive KI-Deployments evaluieren, ist die Frage nach dem MCP-Server meist Teil einer größeren Systemfrage: Was muss Ihr Agent sehen und tun können, und wer ist dafür verantwortlich, diese Verbindung am Laufen zu halten? Silverthread Labs baut produktionsreife MCP-Server als Teil agentischer KI-Deployments. Für eine Bewertung Ihrer spezifischen Integrationsanforderungen buchen Sie ein kostenloses Audit.
Häufig gestellte Fragen#
Was ist MCP in einem Satz? MCP ist ein offener Standard, der KI-Agenten eine einheitliche Möglichkeit gibt, sich mit externen Werkzeugen, Datenbanken und Diensten zu verbinden -- damit Sie die Integration einmal bauen und jeder MCP-kompatible Agent sie nutzen kann.
Ist MCP dasselbe wie eine API? Nein. Eine API legt fest, wie ein bestimmter Dienst seine Funktionalität bereitstellt. MCP ist eine Schicht über APIs, die standardisiert, wie KI-Agenten diese Fähigkeiten entdecken und aufrufen. Ein MCP-Server kapselt typischerweise eine oder mehrere APIs und präsentiert sie dem Agenten in einem Format, über das das Modell schlussfolgern kann.
Welche KI-Tools unterstützen MCP? Stand 2026: Claude (Anthropic), ChatGPT (OpenAI), Google Gemini und Vertex AI, Microsoft Copilot und Azure AI sowie eine wachsende Zahl von Entwicklerplattformen, darunter Cursor, Zed, Replit und Sourcegraph.
Wie viele MCP-Server gibt es? Indexe verzeichneten Ende 2025 über 17.000 Einträge. Die Qualität variiert: Kuratierte Registries wie Glama pflegen rund 10.000 produktionsreife Einträge. Täglich kommen neue Server hinzu.
Ist MCP kostenlos nutzbar? Ja. MCP ist Open Source (MIT-lizenziert), und die Spezifikation wird unter der Linux Foundation gepflegt. Es gibt keine Lizenzgebühren für den Bau von MCP-Servern oder -Clients.
Welche Programmiersprachen unterstützen MCP? Offizielle SDKs sind für Python und TypeScript verfügbar. Community-SDKs existieren für Go, Java, C# und Rust. Das TypeScript-SDK ist derzeit das am häufigsten in Produktivumgebungen eingesetzte.
Wenn ich heute einen MCP-Server baue, funktioniert er noch, wenn sich KI-Modelle ändern? Ja. Modellagnostik ist ein zentrales Designziel von MCP. Ein Server, der heute mit Claude funktioniert, funktioniert auch mit jedem anderen MCP-kompatiblen Modell -- ohne Änderungen am Server selbst. Das Protokoll trennt die Integrationsschicht bewusst von der Modellschicht.
