Was ist MCP? Wie KI-Agenten sich mit Ihren Daten verbinden (Spezifikations-Update 2026)

MCP, das Model Context Protocol, ist ein offener Standard, der es einem KI-Agenten ermöglicht, über eine einzige gemeinsame Schnittstelle auf Tools und Datenquellen zuzugreifen. Anstelle einer maßgeschneiderten Integration pro App spricht ein Client ein einziges Protokoll, und jeder konforme Server kann antworten. Die Spezifikation wurde am 28. Juli 2026 neu geschrieben, und die Änderung ist bedeutend.

Dieser Leitfaden beschreibt, was das Protokoll tut und was sich mit dem Release vom 28.07.2026 geändert hat. Er zeigt auch auf, was nun veraltet ist, wie sich dies von einer reinen API-Integration unterscheidet und wann Sie es gar nicht benötigen. Die Fakten hier entsprechen dem Stand vom 5. August 2026.

Was ist MCP?

Stellen Sie es sich wie eine universelle Steckverbindung vor. Bevor es einen Standard gab, bedeutete die Anbindung eines Assistenten an Ihre Datenbank, Ihr Ticket-System und Ihre Dateien drei maßgeschneiderte Integrationen. Jede hatte ihre eigene Authentifizierung, ihre eigene Fehlerbehandlung und ihren eigenen Wartungsaufwand.

MCP definiert diese Verbindung ein einziges Mal. Ein Client ist die Agenten-Seite. Ein Server kapselt eine Datenquelle oder ein Tool und legt offen, was er tun kann. Der Client fragt den Server, was verfügbar ist, und ruft es dann auf.

Server stellen typischerweise drei Arten von Elementen bereit. Tools sind Aktionen, die der Agent aufrufen kann. Ressourcen sind lesbare Inhalte. Prompts sind wiederverwendbare Vorlagen. Der Client erkennt alle drei zur Laufzeit, anstatt sie fest einprogrammiert zu haben.

Der Name wird oft ungenau verwendet, daher hilft eine Klarstellung: Das Protokoll ist kein Modell, kein Agent und kein Produkt. Es ist das Übertragungsformat (Wire-Format) dazwischen.

Zwei Begriffe erklären die meiste Verwirrung darum. Discovery (Erkennung) bedeutet, dass der Client zur Laufzeit erfährt, was ein Server anbietet. Reuse (Wiederverwendung) bedeutet, dass derselbe Server jedem konformen Client antwortet.

Die Akzeptanz ist nicht mehr nur theoretisch. Die Entwickler des Protokolls berichten von fast einer halben Milliarde Downloads pro Monat über die Tier-1-SDKs hinweg. Die TypeScript- und Python-SDKs haben jeweils bereits die Marke von einer Milliarde Downloads überschritten.

Was sich in der Spezifikation vom 28.07.2026 geändert hat

Dieses Release ist die bisher größte Überarbeitung des Protokolls. Die wichtigste Neuerung ist, dass der Kern nun zustandslos (stateless) ist.

Änderung	Bedeutung
Zustandsloser Kern	Sessions und Handshakes fallen weg. Jede Anfrage enthält ihre eigene Protokollversion und Client-Identität.
Multi-Round-Trip-Anfragen	Ersetzt vom Server initiierte Anfragen, die einen offenen Stream erforderten. Ein Tool kann den Benutzer mitten im Aufruf nach Eingaben fragen.
Header-basiertes Routing	Methoden- und Tool-Namen werden in den Headern Mcp-Method und Mcp-Name übertragen, sodass Gateways das Routing und die Autorisierung direkt über die Header abwickeln können.
Cachebare Listen-Ergebnisse	Listen von Tools, Prompts und Ressourcen enthalten jetzt ttlMs und cacheScope.
Härtung der Autorisierung	RFC 9207 Aussteller-Validierung (Issuer Validation), ein Wechsel von Dynamic Client Registration zu Client ID Metadata Documents sowie ausstellergebundene Anmeldedaten (Issuer-bound Credentials).
Erweiterungs-Framework	Tasks wandern aus dem experimentellen Kern in eine formelle Erweiterung, zusammen mit Apps und Enterprise Managed Authorization.

Man kann diese Liste als eine einzige Entscheidung betrachten, die sechsmal wiederholt wurde. Jede Änderung beseitigt eine Annahme, die den Betrieb von Remote-Servern umständlich machte. Nichts davon ändert etwas daran, was ein Tool tatsächlich tun kann.

Der offizielle Spezifikations-Beitrag vom 28.07.2026 enthält die vollständige Liste der Änderungen. Die SDKs für TypeScript, Python, Go und C# unterstützen dies bereits, Rust befindet sich in der Beta-Phase.

Warum Zustandslosigkeit wichtig ist, wenn Sie einen Server betreiben

Das alte Design setzte eine dauerhafte, bidirektionale Verbindung voraus. Diese eine Annahme war für den Großteil des betrieblichen Aufwands verantwortlich.

Früher benötigte ein Remote-Server Sticky Sessions, damit ein Client immer auf derselben Instanz landete. Er benötigte einen gemeinsamen Session-Speicher, damit der Zustand einen Neustart überlebte. Gateways mussten oft Payloads analysieren, um herauszufinden, was eine Anfrage überhaupt bezweckte.

Nichts davon ist jetzt noch nötig. Ein Server kann hinter einem einfachen Round-Robin-Load-Balancer betrieben werden. Das Routing erfolgt über einen Header. Clients cachen die Tool-Liste so lange, wie es das vom Server angegebene Zeitfenster erlaubt. Das Protokoll hat sich von etwas, das man mit äußerster Vorsicht bereitstellt, zu etwas entwickelt, das man ganz normal bereitstellt.

Damit sind allerdings Migrationskosten verbunden. Server, die auf dem alten Kern aufbauen, müssen angepasst werden, und die Client-Bibliotheken müssen mitziehen.

Die Änderung senkt auch die Hürde, es einfach mal auszuprobieren. Das Aufsetzen eines Servers war früher eine Infrastrukturentscheidung. Jetzt ähnelt es eher dem Deployment eines beliebigen kleinen Webdienstes.

Für jeden, der den MCP-Server eines Drittanbieters evaluiert, lautet die praktische Frage: Welche Version der Spezifikation wird unterstützt und wann erfolgt der Wechsel?

Was veraltet ist und wie viel Zeit Ihnen bleibt

Drei Funktionen werden eingestellt: Roots, Sampling und Logging. Der veraltete HTTP+SSE-Transport ist ebenfalls abgekündigt.

Die Entwickler haben eine Frist von mindestens zwölf Monaten vor der endgültigen Entfernung zugesichert. Das ist großzügig, aber es ist auch eine Deadline. Wenn Sie auf einer dieser vier Funktionen aufgebaut haben, sollten Sie die Migration lieber auf eine Roadmap setzen, statt sie im Backlog verstauben zu lassen.

Überprüfen Sie auch Ihren Client, nicht nur Ihren Server. Ein Client, der auf den alten Transport fixiert ist, wird während der Übergangsfrist weiter funktionieren und danach den Dienst einstellen.

Dynamic Client Registration ist offiziell veraltet und wird durch Client ID Metadata Documents ersetzt. Ausstellergebundene Anmeldedaten (Issuer-bound Credentials) verhindern nun, dass ein für einen Server ausgestelltes Token für einen anderen wiederverwendet (Replay-Angriff) werden kann.

MCP im Vergleich zu einer reinen API-Integration

	Maßgeschneiderte API-Integration	MCP-Server
Aufwand pro Quelle	Jedes Mal neue Authentifizierung, Schemata und Fehlerbehandlung	Ein einziges Protokoll, wiederverwendet
Discovery (Erkennung)	Sie programmieren fest ein, was existiert	Der Client fragt zur Laufzeit nach
Wer es nutzen kann	Die App, in die es eingebaut wurde	Jeder konforme Client
Wartung	Funktioniert nicht mehr, wenn sich die API des Anbieters ändert	Der Server fängt die Änderung ab
Ideal für	Einen einzelnen, tiefen Pfad mit hohem Datenvolumen	Viele Quellen, auf die ein Agent zugreifen soll

Ein weiterer Aspekt ist, wer den Connector wartet. Ein vom Anbieter veröffentlichter Server entwickelt sich mit dessen Produkt weiter – eine Arbeit, die Sie sich somit sparen.

Ehrlicherweise muss man sagen, dass MCP für eine einzelne Integration weder schneller noch günstiger ist. Es spielt seine Stärken aus, wenn die Anzahl der Quellen wächst oder wenn mehrere Agenten ohne erneuten Entwicklungsaufwand auf dieselbe Quelle zugreifen sollen.

Was Sie erstellen können, sobald eine Datenquelle angebunden ist

Die Anbindung ist nur die Infrastruktur. Der eigentliche Grund für den Aufwand ist das Endergebnis.

Sobald eine Datenquelle angebunden ist, kann ein Agent die aktuellen Zahlen abrufen und die Analyse durchführen. Das Ergebnis ist fertig einsatzbereit: ein Diagramm, eine schriftliche Zusammenfassung, ein Foliensatz. Der Mehrwert entsteht durch den Wegfall des Exportschritts, nicht durch das Protokoll selbst. Dieses Endergebnis rechtfertigt das Setup auch intern. Eine Verbindung, die niemand für Berichte nutzt, wird irgendwann stillschweigend abgeschaltet.

Powerdrill Bloom liefert einen Server nach diesem Muster aus. Laut eigener Dokumentation authentifiziert er sich mit Ihrer User ID und Ihrem Project API Key. Ein Client kann dann die Datensätze in Ihrem Konto durchsuchen, Details zu einzelnen Datensätzen abrufen und Aufgaben ausführen, indem er Fragen in natürlicher Sprache stellt. Er funktioniert mit Claude Desktop und anderen konformen Clients. Die Ankündigung des MCP-Servers beschreibt die Einrichtung, und die Seite für Datenkonnektoren listet die anderen Quelltypen auf.

Wann Sie MCP überhaupt nicht benötigen

Dieser Teil wird in den meisten Erklärungen übersprungen, daher sollte er hier ganz klar angesprochen werden.

Wenn Ihre Daten als Datei vorliegen, benötigen Sie kein Protokoll. Sie benötigen einen Upload. Ein Quartalsexport, eine CSV, die Ihnen jemand per E-Mail geschickt hat, ein PDF-Kontoauszug – nichts davon rechtfertigt das Aufsetzen eines Servers. Ziehen Sie die Datei einfach hinein und stellen Sie Ihre Frage.

Stellen Sie sich vor dem Aufbau eine Frage: Wird genau dieser Export nächsten Monat wieder benötigt, und zwar von jemand anderem als Ihnen?

MCP lohnt sich, wenn die Quelle live und wiederkehrend ist. Eine Datenbank, die sich stündlich ändert, eine Ticket-Warteschlange, eine Lagertabelle, die einen wöchentlichen Bericht speist. Der Test ist, ob Sie andernfalls nächste Woche dasselbe Dokument erneut exportieren müssten.

Es gibt auch eine Sicherheitsdimension. Eine angebundene Quelle ist eine dauerhafte Freigabe, kein einmalig geteilter Inhalt. Die Autorisierungsänderungen vom 28.07.2026 wurden genau deshalb eingeführt, weil dieser Unterschied eine Rolle spielt.

Die Kurzfassung

MCP ist eine Standardverbindung zwischen Agenten und Datenquellen. Das Release vom 28.07.2026 hat den Kern zustandslos gemacht, das Routing in die Header verlagert, Listen-Ergebnisse cachebar gemacht und die Autorisierung verschärft. Roots, Sampling, Logging und der alte HTTP+SSE-Transport sind mit einer Übergangsfrist von zwölf Monaten veraltet.

Für eine einmalige Datei können Sie das alles überspringen. Testen Sie Powerdrill Bloom kostenlos – laden Sie die Datei hoch, stellen Sie Ihre Frage in natürlicher Sprache und exportieren Sie das Diagramm oder die Präsentation. Wenn Sie Server-Optionen vergleichen möchten, finden Sie hier die besten MCP-Plattformen.

Häufig gestellte Fragen

Wofür steht MCP?

Model Context Protocol. Es ist ein offener Standard zur Anbindung von KI-Clients an Tools und Datenquellen über eine einzige Schnittstelle. Jede neue Quelle vermeidet so eine maßgeschneiderte Integration.

Was hat sich in der MCP-Spezifikation vom 28.07.2026 geändert?

Der Kern wurde zustandslos, wodurch Sessions und Handshakes wegfallen. Multi-Round-Trip-Anfragen ersetzten vom Server initiierte Anfragen über offene Streams, und das Routing wurde in die Header Mcp-Method und Mcp-Name verlagert. Listen-Ergebnisse wurden cachebar und die Autorisierung wurde durch Aussteller-Validierung und ausstellergebundene Anmeldedaten gehärtet.

Ist MCP dasselbe wie eine API?

Nein. Eine API ist die Schnittstelle eines bestimmten Anbieters zu einem einzelnen System. Das Protokoll ist ein gemeinsamer Wrapper, den viele Systeme implementieren können, sodass jeder konforme Client sie ohne maßgeschneiderten Code pro Quelle erkennen und aufrufen kann.

Was ist in der neuen MCP-Spezifikation veraltet?

Roots, Sampling und Logging sind veraltet, ebenso wie der herkömmliche HTTP+SSE-Transport. Dynamic Client Registration weicht Client ID Metadata Documents. Die Entwickler haben eine Frist von mindestens zwölf Monaten vor der endgültigen Entfernung angekündigt.

Benötige ich MCP, um eine Tabellenkalkulation mit KI zu analysieren?

Nein. Für eine Datei, die Sie bereits haben, ist das Hochladen einfacher und schneller. Die Einrichtung des Protokolls lohnt sich, wenn die Quelle live ist und Sie andernfalls dieselben Daten regelmäßig neu exportieren müssten.