Was ist MCP, und warum sprechen plötzlich alle KI-Tools diese Sprache?
Den größten Teil des letzten Jahrzehnts bedeutete die Verbindung eines KI-Modells mit den Tools Ihres Unternehmens eine individuelle Integration für jedes Paar. Model Context Protocol, der offene Standard, den Anthropic im November 2024 einführte, ersetzte das durch einen Stecker, der überall passt — und OpenAI, Google und Microsoft haben ihn seither alle übernommen. Hier ist, wie es tatsächlich funktioniert, und eine echte Checkliste, bevor Sie eines mit den Daten Ihres Teams verbinden.
Öffnen Sie die Desktop-App von Claude und bitten Sie sie, die offenen Pull-Requests Ihres Teams zu prüfen, und sie kann das einfach tun. Nicht, weil Anthropic eine GitHub-Integration in Claude eingebaut hat. Sondern weil irgendwo — Ihr IT-Team, ein Anbieter, ein Entwickler auf GitHub — jemand ein kleines Programm geschrieben hat, das ein Protokoll namens MCP spricht, und Claude bereits weiß, wie es mit allem sprechen kann, das dieses Protokoll spricht. Dasselbe gilt inzwischen für ChatGPT, Googles Gemini und Microsoft Copilot. Diese Konvergenz ist, mehr als jede einzelne Feature-Veröffentlichung, der Grund, warum MCP zu der Sache wurde, für die fast jeder KI-Anbieter im vergangenen Jahr Unterstützung aufgebaut hat.
Was MCP tatsächlich ist
MCP steht für Model Context Protocol. Anthropic entwarf es und veröffentlichte die Spezifikation zusammen mit den ersten SDKs am 25. November 2024 als Open Source. Das eigene Launch-Material beschrieb die Idee mit einer Analogie, die haften blieb: Stellen Sie sich MCP als einen USB-C-Anschluss für KI-Anwendungen vor — ein physischer Steckerstandard statt eines anderen Kabels für jedes Zubehör. Beim Launch nannte Anthropic frühe Anwender, die bereits MCP-Unterstützung in ihre eigenen Produkte einbauten, darunter die Enterprise-Software-Unternehmen Block und Apollo sowie die Entwickler-Tool-Hersteller Zed, Replit, Codeium und Sourcegraph. Claudes Desktop-App wurde am selben Tag mit der Fähigkeit ausgeliefert, MCP-Server lokal auf dem eigenen Rechner einer Person auszuführen.
Das Problem, das es löst: N Tools mal M Datenquellen
Das Problem, das MCP löst, hat einen Namen, den Ingenieure beiläufig verwenden: das N-mal-M-Integrationsproblem. Nehmen wir an, ein Unternehmen nutzt fünf KI-Tools, die auf Unternehmensdaten zugreifen müssen — Claude, ChatGPT, GitHub Copilot, Cursor und einen internen Support-Bot — und diese Daten liegen an acht Orten: Slack, GitHub, einer Postgres-Datenbank, Salesforce, Notion, Google Drive, Jira und einer internen API. Ohne ein gemeinsames Protokoll erfordert die sinnvolle Verbindung jedes Tools mit jeder Quelle bis zu vierzig separate Integrationen — fünf mal acht — jede mit ihrem eigenen Authentifizierungsschema, ihrer eigenen Fehlerbehandlung und ihrer eigenen Wartungslast, sobald eine dieser APIs ihre Form ändert. Fügen Sie ein sechstes KI-Tool hinzu, und die Zahl springt auf achtundvierzig. In der Praxis baute niemand alle vierzig. Jeder KI-Anbieter baute die Handvoll, die er für die Entwicklungszeit für wert hielt, und alles andere blieb manuell: kopieren, einfügen, erneut erklären, wiederholen.
MCP verwandelt die Multiplikation in eine Addition. Ein Unternehmen, das möchte, dass Claude aus seiner Postgres-Datenbank liest, baut keinen Claude-spezifischen Postgres-Connector. Es baut — oder nutzt einen bereits von jemand anderem veröffentlichten — einen MCP-Server, der Postgres bereitstellt, und dieser Server funktioniert mit Claude, ChatGPT, Gemini oder jedem anderen MCP-kompatiblen Agenten ohne weiteren Code. Anthropics eigene Liste nannte beim Launch vorgefertigte Server für Google Drive, Slack, GitHub, Git, Postgres und ein Browser-Automatisierungstool namens Puppeteer. Der Punkt war nie, dass Anthropic alle davon bauen würde. Es geht darum, dass jeder es könnte, und der Katalog verfügbarer Server ist inzwischen weit über das hinausgewachsen, was ein einzelnes Unternehmen personell stemmen könnte.
Wie das Protokoll tatsächlich funktioniert
Entfernt man die Verpackung, ist MCP ein recht schlichtes Client-Server-Protokoll, bewusst unglamourös gestaltet. Es definiert drei Rollen. Ein Host ist die Anwendung, die eine Person tatsächlich öffnet — Claude Desktop, eine IDE wie Cursor, die ChatGPT-App. Der Host bettet einen MCP-Client ein, der eine direkte, zustandsbehaftete Verbindung zu einem MCP-Server öffnet — einem kleinen Programm, das ein bestimmtes System bereitstellt: eine Datenbank, ein Ticketing-Tool, ein Dateisystem, eine interne API. Client und Server tauschen Nachrichten im Format JSON-RPC 2.0 aus, einem leichtgewichtigen Remote-Procedure-Call-Format, das in bestehender Infrastruktur bereits verbreitet ist, über einen von zwei Transportwegen: stdio, wenn der Server ein Programm ist, das lokal auf demselben Rechner läuft, oder Streamable HTTP, wenn es sich um einen gehosteten Dienst handelt, der anderswo läuft.
Was ein Server bereitstellen kann, läuft auf drei Primitive hinaus. Tools sind Funktionen, die das Modell aufrufen kann, um eine Aktion auszuführen — create_task, run_query, send_message — und das Modell entscheidet basierend auf dem Gespräch, wann es eines aufruft. Resources sind schreibgeschützter Kontext, den der Host einbeziehen und dem Modell übergeben kann, ohne dass es danach fragen muss — der Inhalt einer Datei, ein Datenbankschema, ein Support-Ticket. Prompts sind wiederverwendbare, benutzerausgelöste Vorlagen — ein vorgefertigtes „Fasse diesen Thread zusammen" oder „Entwerfe ein Status-Update", das eine Person explizit aufruft, statt etwas, das das Modell von selbst entscheidet zu tun. Ein gut gebauter Server macht explizit, welches der drei er für eine bestimmte Fähigkeit anbietet, denn genau diese Unterscheidung bestimmt, ob ein verbundenes KI-Tool etwas nur ansehen oder auch verändern kann.
Wer es sonst noch übernahm, und wann
MCPs erste Monate waren ein reines Anthropic-Projekt. Das änderte sich schnell, und zwar auf eine Weise, die in der KI-Branche wirklich ungewöhnlich ist: Direkte Konkurrenten einigten sich auf das Protokoll eines einzelnen Unternehmens, statt ihre eigenen zu veröffentlichen. OpenAI fügte im März 2025 MCP-Unterstützung zu seinem Agents SDK hinzu und ermöglichte Entwicklern, Agenten-Workflows mit jedem MCP-Server zu verbinden, statt maßgeschneiderte, OpenAI-spezifische Tool-Integrationen zu bauen. Im darauffolgenden Monat bestätigte Google DeepMind, dass Gemini und das eigene Agenten-Entwicklungskit MCP ebenfalls unterstützen würden — ein Schritt, den Google mit seinem eigenen ergänzenden Protokoll Agent2Agent verband, das darauf abzielt, dass unabhängige Agenten sich untereinander koordinieren können, statt nur mit Tools. Bis Mai 2025 hatte Microsoft native MCP-Unterstützung in Windows 11 gebracht, über das, was es Windows AI Foundry nennt, wobei die Unterstützung auch in GitHub Copilot und Copilot Studio Einzug hielt.
Diese vier Unternehmen sind sich bei Modellarchitektur, Preisgestaltung oder Plattformstrategie in kaum etwas einig. Alle vier liefern inzwischen Produkte aus, die dasselbe Protokoll sprechen, um einen Agenten mit einem Tool zu verbinden. Das ist in dieser Branche selten genug, um die eigentliche Geschichte zu sein — mehr als jede einzelne Funktion, die MCP ermöglicht.
Warum das eine Vertrauensfrage ist, nicht nur Verkabelung
Diese Konvergenz ist wirklich nützlich, und genau deshalb verdient MCP Prüfung statt blindes Vertrauen. Ein Protokoll, das es trivial macht, dass ein Agent sich mit den Systemen Ihres Unternehmens verbindet, ist ein Protokoll, das es trivial macht, dass eine schlecht gebaute oder schlecht konfigurierte Verbindung dieselben Systeme erreicht. MCP selbst verhindert das nicht. Die Spezifikation definiert, wie ein Client und ein Server miteinander sprechen — sie sagt nichts darüber aus, wer eine Verbindung gewähren darf, was diese Verbindung berühren darf, oder ob jemand es bemerken wird, wenn etwas schiefgeht. Diese Entscheidungen liegen vollständig bei demjenigen, der den spezifischen Server oder Client vor Ihnen gebaut oder konfiguriert hat. Manche Anbieter bauen all das sorgfältig. Manche bauen es überhaupt nicht, und das Protokoll wird sie nicht daran hindern.
MCP ist ein Übertragungsprotokoll, kein Zugriffskontrollsystem. Es standardisiert, wie ein Agent ein Tool bittet, etwas zu tun. Ob diese Bitte begrenzt, protokolliert und widerrufbar ist, ist eine Entscheidung, die jemand darüber hinaus getroffen hat — oder nicht.
Eine Checkliste, bevor Sie eines verbinden
Bevor Ihr Team einen MCP-Server verbindet — sei es ein Produkt eines Anbieters, ein Open-Source-Tool, das jemand auf GitHub gefunden hat, oder etwas intern Gebautes — trennen sechs Fragen eine kontrollierte Verbindung von einer offenen Tür. Keine von ihnen erfordert das Lesen der Spezifikation. Sie erfordern nur, dass jemand fragt, bevor er auf „Genehmigen" klickt, und die Antwort, die der Verbindungsbildschirm zurückgibt, tatsächlich liest.
| Fragen Sie dies | Wie gut aussieht | Achten Sie auf |
|---|---|---|
| Welche Berechtigungen oder Tools fordert es an? | Aufgelistet Eine benannte, konkrete Liste, die Sie vor der Genehmigung lesen können — „Aufgaben erstellen, Nachrichten in diesem Kanal lesen." | Pauschal „Vollständiger Kontozugriff" ohne aufgelistete Angabe, was es tatsächlich tun kann. |
| Ist es nur lesend, oder kann es schreiben und handeln? | Getrennt Lesezugriff standardmäßig; jede Aktion, die Daten ändert, benötigt eine eigene sichtbare Genehmigung. | Gebündelt Schreibzugriff automatisch enthalten, ohne Möglichkeit zu erkennen, welche Fähigkeit was tut. |
| Ist es pro Person oder team-weit geteilt? | Pro Person Jede Person meldet sich mit ihrem eigenen Login an; der Agent kann nur sehen, was diese Person sehen kann. | Geteilt Ein API-Schlüssel oder Dienstkonto, das vom gesamten Team genutzt wird und individuelle Berechtigungen umgeht. |
| Gibt es ein Audit-Log dafür, was es getan hat? | Protokolliert Jeder Tool-Aufruf wird aufgezeichnet — wer ihn verbunden hat, was er berührt hat, und wann. | Unprotokolliert Keine Aufzeichnung außer dem, was das KI-Tool selbst Ihnen zu berichten entscheidet. |
| Kann es sofort widerrufen werden? | Sofort Ein Schalter, sofort wirksam, auf einer Einstellungsseite, die Sie kontrollieren. | Verzögert Der Widerruf erfordert ein Support-Ticket, einen Anruf beim Anbieter, oder ist überhaupt nicht möglich. |
| Bricht der Widerruf irgendetwas anderes? | Isoliert Auf diese eine Verbindung begrenzt; das Abschalten betrifft nur diese. | Verknüpft Teilt sich eine Zugangsdaten mit anderen Tools, sodass der Widerruf eines Tools stillschweigend drei andere beschädigt. |
Wie eine gut gebaute Verbindung tatsächlich aussieht
FabricLoops eigenes MCP-Setup ist eine konkrete Antwort auf diese Checkliste — nicht weil es ungewöhnlich ist, sondern weil jeder Teil direkt einer der sechs obigen Fragen entspricht, und es lohnt sich, die tatsächliche Mechanik zu benennen statt der Marketing-Version davon. FabricLoop läuft gleichzeitig in beiden Rollen: Es ist ein MCP-Server, mit dem sich externe Tools verbinden, sodass Cursor, Claude oder ChatGPT eine Aufgabe erstellen, einen Kommentar hinzufügen oder eine Notiz lesen können, unter Verwendung der eigenen FabricLoop-Berechtigungen einer bestimmten Person — und es ist ein MCP-Client, der sich nach außen verbindet, sodass ein Kanal die MCP-App eines Anbieters wie GitHub oder Linear einbinden und per @-Erwähnung wie ein Teammitglied ansprechen kann.
Jede Verbindung, in beide Richtungen, beginnt mit einer Person, nicht mit einem Workspace. Das Verbinden eines externen Clients wie Cursor öffnet einen OAuth-Zustimmungsbildschirm unter app.fabricloop.com/oauth/consent, wo diese Person einen Workspace auswählt und die spezifischen Tools genehmigt, die der Client anfordert — der Client kann dann nur mit den auf diesem Bildschirm gewährten Berechtigungen handeln, unter den Berechtigungen genau dieser einen Person, niemals über ein geteiltes Dienstkonto. Die umgekehrte Richtung läuft genauso: Ein Admin kann die MCP-App eines Anbieters für das gesamte Team aktivieren, aber jede Person muss trotzdem ihre eigene Anmeldung abschließen, bevor es für sie funktioniert, und ein Admin kann diese App auf einen reinen Lesemodus setzen oder sie auf eine Zulassungsliste bestimmter Tools beschränken, statt auf alles, was der Anbieter bereitstellt.
Jeder verbundene Client erscheint auf einem Einstellungsbildschirm neben einer Widerrufen-Schaltfläche, die ihn sofort trennt — auf der eigenen Seite der Person, nicht in einem Support-Ticket. Bei Enterprise-Plänen landet diese Aktivität — einschließlich MCP-Genehmigungen und was ein verbundener Agent tatsächlich getan hat — in einem Audit-Log, das ein Sicherheitsteam auf Abruf überprüfen kann, statt in Screenshots, die nachträglich aus einem Chat-Thread herausgezogen werden.
Nichts davon ist exotische Technik. Es ist eine kleine, bewusst unglamouröse Reihe von Entscheidungen, die konsequent wiederholt werden: begrenzen, an eine Person binden, protokollieren, widerrufbar machen ohne Kollateralschäden. Das ist dasselbe Argument, das diese Website allgemeiner über Legibility macht — Zugriff, den man benennen, protokollieren und widerrufen kann, schlägt Zugriff, über den niemand nachdenken muss — und MCP liefert das nur, wenn jemand es so baut. Das Protokoll standardisiert die Verkabelung. Es macht die Governance nicht automatisch.
Die Entscheidung, die tatsächlich zählt
MCP wird nicht verschwinden, und sich an diesem Punkt dagegen zu wehren, ist ein bisschen so, als würde man sich gegen USB wehren. Jeder große Modellanbieter liefert es inzwischen aus, die Liste verfügbarer Server wächst weiter, und ein Agent, der Ihre Tools nicht erreichen kann, ist für die meiste reale Arbeit ein Agent, der nicht viel tun kann. Die interessante Entscheidung ist nicht, ob Sie einem KI-Tool erlauben, sich mit Ihren Systemen zu verbinden — zunehmend wird eine Version dieser Entscheidung bereits für Sie getroffen, eine Integration nach der anderen, während Tools, die Ihr Team bereits nutzt, still und heimlich MCP-Unterstützung unter einer Funktion hinzufügen, in die Sie geklickt haben, ohne das Kleingedruckte zu lesen. Die Entscheidung, die tatsächlich noch bei Ihnen liegt, ist, was Sie prüfen, bevor Sie auf „Genehmigen" klicken.
MCP standardisierte, wie ein KI-Agent ein Tool bittet, etwas zu tun. Es hat nichts dazu beigetragen, zu standardisieren, ob es sicher ist, diese Bitte zu gewähren — dieser Teil ist und bleibt eine Entscheidung der Person, die auf „Genehmigen" klickt.