Anthropic, Simon Willison und die sessionlose MCP-Wende

Anthropic führte MCP 2024 ein, doch Simon Willison hielt Terminal-Tools später für flexibler. Die Spezifikation vom 28. Juli 2026 hat dieses Urteil nun teilweise umgekehrt. Sie entfernt Protokollsitzungen und macht Remote-MCP-Aufrufe zu eigenständigen Anfragen.

Diese Änderung hat Willisons Interesse neu geweckt und zwei Projekte inspiriert: mcp-explorer und datasette-mcp. Noch wichtiger ist, dass sie die architektonische Schwäche angeht, die Remote-MCP-Server schwieriger bereitzustellen machte als gewöhnliche HTTP-Dienste.

Die Geschichte von Anthropic und Simon Willison ist daher nicht einfach ein weiteres Protokoll-Update. Sie ist ein Test dafür, ob MCP aufhören kann, mit Kommandozeilen-Tools zu konkurrieren, und eine besser begründbare Rolle findet. Skills bleiben attraktiv, um Agenten den Umgang mit bestehender Software beizubringen, während sessionloses MCP strukturierte Remote-Tools, Erkennung, Autorisierung und gemeinsame Infrastruktur bietet.

Sessionloses MCP entfernt die Sitzung aus jedem Anfragepfad

Die neue Spezifikation wandelt MCP von einem verbindungszentrierten in ein anfragezentriertes Protokoll um.

Das Model Context Protocol definiert eine Standardschnittstelle, über die KI-Agenten externe Tools entdecken und aufrufen können. Anthropic führte es im November 2024 ein, und Entwickler erstellten schnell Server für Datenbanken, Browser, Kommunikationsplattformen und Geschäftsanwendungen.

Frühere Versionen verlangten vor regulären Tool-Aufrufen einen Initialisierungsprozess. Client und Server tauschten ihre Protokollversionen, Fähigkeiten und Identifikationsinformationen aus. Diese Aushandlung schuf Kontext, den nachfolgende Nachrichten voraussichtlich beibehalten sollten.

HTTP-Server konnten zudem eine Mcp-Session-Id ausgeben. Clients sendeten diese Kennung dann bei späteren Anfragen zurück. Dadurch verhielt sich eine Folge von Aufrufen wie eine fortlaufende Unterhaltung zwischen einer bestimmten Client- und Serverinstanz.

Dieses Design hatte Folgen für die Infrastruktur. Ein Load Balancer musste zusammengehörige Aufrufe an die richtige Instanz leiten oder Sitzungsdaten in gemeinsamem Speicher ablegen. Betreiber benötigten zudem Regeln für Ablauf, Wiederverbindung, Wiederherstellung und Bereinigung.

Die finale Revision 2026-07-28 entfernt den obligatorischen initialize-Handshake. Sie entfernt außerdem die Protokollsitzung und den zugehörigen Header. Jede Anfrage enthält nun die Informationen, die nötig sind, um sie unabhängig zu interpretieren.

Das offizielle MCP-Release beschreibt die Revision als die größte Änderung seit dem Start des Protokolls. Zum sessionlosen Kern kommen Erweiterungen, überarbeitete Tasks-Unterstützung, Änderungen bei der Autorisierung und ein formaler Funktionslebenszyklus hinzu.

Ein Client kann nun direkt einen Tool-Aufruf senden. Die Anfrage enthält seine Protokollversion, Methode, den Tool-Namen, Client-Informationen und relevante Fähigkeiten. Jede kompatible Serverinstanz kann sie verarbeiten, ohne sich auf einen vorherigen Austausch zu stützen.

Die Änderung fügt außerdem server/discover hinzu, womit Clients bei Bedarf Serverfähigkeiten abfragen können. Die Erkennung zwingt nicht länger jeden Aufrufer dazu, eine Protokollsitzung aufzubauen und aufrechtzuerhalten.

Das bedeutet nicht, dass jede Anwendung ihren Zustand verwerfen muss. Ein Browser-Automatisierungsdienst, Warenkorb, eine Datenbanktransaktion oder ein Recherche-Workflow kann weiterhin Informationen über mehrere Aufrufe hinweg behalten.

Entscheidend ist, wo diese Informationen liegen und wie sie adressiert werden. Statt sie hinter einer Sitzung zu verbergen, kann der Server eine explizite Kennung zurückgeben. Das Modell übermittelt diese Kennung bei späteren Aufrufen.

Ein Browser-Server könnte nach dem Start einer Instanz eine browser_id zurückgeben. Spätere Tools können diesen Wert beim Navigieren, Erfassen einer Seite oder Schließen des Browsers annehmen. Ein Datenbank-Tool kann dasselbe Muster für eine Transaktionskennung anwenden.

Der angenommene Vorschlag für sessionloses MCP beschreibt diese Werte als explizite Zustands-Handles. Sie sind kein neuer MCP-Datentyp. Es handelt sich um gewöhnliche Tool-Ein- und -Ausgaben, die den Anwendungszustand sichtbar machen.

Diese Sichtbarkeit ist für Agenten wichtig. Ein Orchestrator kann ein Handle mit einem Subagenten teilen und ein anderes isoliert halten. Er kann die Kennung auch für spätere Arbeit speichern oder an einen anderen autorisierten Prozess übergeben.

Listenoperationen gewinnen einen weiteren Vorteil. Wenn sich Tools und Ressourcen nicht länger gemäß einer mehrdeutigen Sitzung ändern dürfen, können Clients Erkennungsergebnisse sicherer cachen. Das reduziert wiederholte Aufrufe bei kurzlebigen Agenten.

Sessionloses MCP passt außerdem besser zu vertrauten HTTP-Vorgängen. Remote-Server können standardmäßiges Round-Robin-Balancing, gewöhnliches Gateway-Routing, anfragebasierte Authentifizierung und etablierte Observability-Systeme verwenden.

Diese Kombination hat Willisons Aufmerksamkeit erneut geweckt. Das Update verkürzt nicht nur den Handshake. Es beseitigt eine architektonische Festlegung, die zuvor in jede Bereitstellung und jede Client-Implementierung hineinwirkte.

Warum die Anthropic-Simon-Willison-Wende wichtig ist

Willisons erneutes Interesse ist bedeutsam, weil seine frühere Kritik eine tatsächliche Abkehr von MCP unter Nutzern von Coding-Agenten erfasste.

MCP zog während eines Großteils von 2025 große Aufmerksamkeit auf sich. Sein Nutzenversprechen war leicht zu verstehen: Eine Server-Schnittstelle implementieren und dann dieselben Tools mehreren kompatiblen KI-Clients bereitstellen.

Gleichzeitig wurden Coding-Agenten besser. Sie erhielten verlässlichen Terminalzugriff, besseren Umgang mit der Shell und stärkere Fähigkeiten zur Prüfung von Dokumentation. Viele konnten eine Bibliothek installieren oder eine konventionelle API mit curl aufrufen.

Das schuf eine direkte Herausforderung. Ein gut dokumentiertes Kommandozeilenprogramm bietet bereits eine kombinierbare Tool-Schnittstelle. Der Agent kann Befehle verknüpfen, Ausgaben umleiten, kleine Skripte schreiben und Fehler prüfen, ohne einen Protokolladapter zu benötigen.

Skills stärkten diesen Weg. Ein Skill ist ein Paket aus Anweisungen, Skripten und Referenzen, das einem Agenten beibringt, wie er eine Aufgabe ausführt. Er kann eine bestehende API erklären, ohne dass deren Betreiber einen MCP-Server betreiben muss.

Willison fasste seine Skepsis in seinem Rückblick auf 2025 zusammen. Für Coding-Agenten bevorzugte er Kommandozeilenprogramme und Bibliotheken gegenüber MCP. Diese Optionen gaben dem Modell mehr Freiheit und vermieden zugleich eine weitere Dienstschicht.

Die Kritik lautete nie, dass strukturierte Tool-Aufrufe keinen Wert hätten. Die schwierigere Frage war, ob MCP genügend zusätzlichen Nutzen bot, um Sitzungen, Transportverwaltung, Arbeit an der Client-Kompatibilität und Kontext-Overhead zu rechtfertigen.

Sessionloses MCP verringert diese Lücke. Ein kleines Remote-Tool kann sich nun stärker wie ein konventioneller Web-Endpunkt verhalten und zugleich einen maschinenlesbaren Vertrag für Agenten-Clients bewahren.

Willisons Analyse zu sessionlosem MCP verbindet diese Änderung mit zwei Experimenten. Das erste ist mcp-explorer, das MCP-Server leichter untersuchbar und verständlich machen soll. Das zweite ist datasette-mcp, das den neuen Ansatz auf Datasette anwendet.

Datasette ist Willisons Open-Source-System zur Erkundung und Veröffentlichung strukturierter Daten. Es stellt Datenbanken bereits über Weboberflächen und APIs bereit. MCP bietet eine weitere Oberfläche, die speziell für Sprachmodelle mit Tool-Nutzung konzipiert ist.

Die Kombination ist aufschlussreich. Eine Datasette-Bereitstellung ist von Natur aus remote, strukturiert und wird von mehreren Nutzern geteilt. Sie passt nicht so nahtlos zum lokalen Kommandozeilenmodell wie ein Entwicklertool, das neben einem Agenten installiert ist.

Ein MCP-Server kann Datenbank-Tools über Schemas anbieten, die Clients verstehen. Agenten können verfügbare Operationen prüfen, bevor sie Abfragen senden. Serverbetreiber behalten die Kontrolle über Authentifizierung, Berechtigungen, Limits und Implementierungsdetails.

Das macht den Vergleich zwischen Anthropic und Simon differenzierter als MCP gegen Skills. Ein Skill kann einem Agenten beibringen, wie eine API abgefragt wird. MCP kann vielen Clients einen gemeinsamen Vertrag zum Entdecken und Aufrufen dieser API geben.

Beide Ansätze können auch zusammenwirken. Ein Skill kann beschreiben, wann ein MCP-Server zu verwenden ist, seine Fachkonzepte erläutern oder einen Workflow über mehrere Tools hinweg bereitstellen. MCP kann die Grenze der Remote-Ausführung handhaben.

Diese Aufteilung verringert den Druck auf MCP, die universelle Antwort auf jede Agentenaktion zu werden. Lokale Befehle können lokal bleiben. Bibliotheken können flexible Coding-Aufgaben bedienen. Skills können Betriebswissen bündeln.

MCP erhält dort eine klarere Rolle, wo der Server die Ausführung kontrolliert und mehrere Clients dieselbe auffindbare Schnittstelle benötigen. Unternehmensdaten, gehostete Suche, gemeinsame Dienste und authentifizierte Geschäftssysteme passen zu diesem Muster.

Die Einfachheit des Protokolls verändert daher die Wettbewerbsfrage. Entwickler müssen nicht mehr fragen, ob jedes Tool einen MCP-Wrapper verdient. Sie können fragen, ob eine Remote-Fähigkeit von standardisierter Erkennung und Aufruf profitiert.

Das ist ein kleineres Versprechen als die weitreichendsten frühen Deutungen von MCP. Es ist aber auch glaubwürdiger. Standards werden oft nützlich, nachdem ihre Grenzen klarer geworden sind.

Sessionlose Anfragen machen MCP passend für gewöhnliche Cloud-Infrastruktur

MCP 2.0 ist wichtig, weil es spezialisierte Koordination aus dem üblichen Bereitstellungspfad entfernt.

Der angenommene Vorschlag für sessionloses MCP nennt drei Probleme des alten Initialisierungsmodells. Sitzungen erschwerten die Skalierung, schwächten die Fehlerwiederherstellung und erhöhten den Implementierungsaufwand auf beiden Seiten.

Betrachten wir ein Remote-Suchtool, das auf drei Serverinstanzen läuft. Bei einem sitzungsorientierten Design müssten spätere Aufrufe möglicherweise dieselbe Instanz erreichen, die die Initialisierung verarbeitet hat. Ein einfacher Round-Robin-Load-Balancer kann dieses Ergebnis nicht garantieren.

Betreiber können das Problem mit Sticky Routing lösen. Sie können Sitzungsdaten auch in einem gemeinsamen Dienst speichern. Beide Ansätze führen operativen Zustand, zusätzliche Fehlermodi und neue Anforderungen an die Überwachung ein.

Sticky Sessions können Arbeit ungleich verteilen. Gemeinsame Speicher schaffen eine weitere Abhängigkeit. Serverneustarts können lokalen Zustand ungültig machen, während Clients Fehler erkennen und die Initialisierung wiederholen müssen.

Mit dem neuen Anfragemodell kann jede fehlerfreie Instanz einen kompatiblen Tool-Aufruf verarbeiten. Das Gateway kann anhand von Methoden- und Tool-Metadaten statt anhand des Verbindungsverlaufs routen.

Diese Änderung macht auch serverlose Bereitstellungen plausibler. Plattformen, die Instanzen nach Bedarf starten und stoppen, funktionieren am besten, wenn Anfragen nicht vom Speicher einer früheren Anfrage abhängen.

Der Server benötigt weiterhin dauerhaften Speicher für wirklich dauerhaften Anwendungszustand. Sessionloses MCP beseitigt weder Datenbanken noch Objektspeicher, Browser-Worker oder Job-Warteschlangen. Es beseitigt die Annahme, dass Protokollzustand diese begleiten muss.

Langlaufende Vorgänge liegen nun in einem erweiterungsbasierten Modell. Ein Server kann ein Task-Handle zurückgeben, während der Client diesen Task später über explizite Operationen prüft, aktualisiert oder abbricht.

Der Unterschied ist wichtig. Versteckter Sitzungszustand koppelt einen Workflow an eine Transportbeziehung. Ein Task-Handle macht den Workflow zu einer adressierbaren Ressource, die andere autorisierte Komponenten verwalten können.

Multi Round-Trip Requests behandeln einen weiteren schwierigen Fall. Manche Tools benötigen vor dem Abschluss mehr Informationen von einem Nutzer oder Client. Frühere Implementierungen verknüpften diesen Austausch mit einer bestehenden Sitzung.

Das neue Design erlaubt eine serverinitiierte Anfrage nur, während der Server eine Client-Anfrage verarbeitet. Korrelationsdaten durchlaufen den Anfrage- und Antwortzyklus und vermeiden so eine dauerhafte Protokollsitzung.

Das schränkt bestimmte Verhaltensweisen ein. Ein Server kann einen Client nicht unerwartet lange nach dem auslösenden Aufruf kontaktieren. Diese Begrenzung verringert die Flexibilität, gibt Nutzeraufforderungen jedoch einen klareren Ursprung und Lebenszyklus.

Auch die Tool-Erkennung lässt sich leichter weiterleiten und cachen. Die Spezifikation ergänzt HTTP-Header um Methoden- und Tool-Metadaten. Gateways können diese Metadaten prüfen, ohne jeden Request-Body analysieren zu müssen.

Server können Listenantworten mit einem Time-to-Live-Wert versehen. Clients können Tool-Informationen dann innerhalb des zulässigen Zeitraums wiederverwenden, statt für jeden kurzlebigen Subagenten dieselbe Liste erneut anzufordern.

Der zustandslose Vorschlag warnt davor, dass das frühere Verhalten wiederholten Discovery-Traffic erzeugen konnte, der proportional zur Anzahl der Subagenten multipliziert mit der Anzahl der Server war. Zustandslose Listen geben Orchestratoren eine bessere Grundlage, diese Kosten zu vermeiden.

Das gewinnt an Bedeutung, da Agentensysteme zunehmend verteilter werden. Eine Nutzeranfrage kann einen Planer, mehrere spezialisierte Worker und einen Verifizierer auslösen. Wenn Initialisierung und Discovery für jeden Zweig wiederholt werden, steigen Latenz und Datenverkehr.

Das überarbeitete Protokoll übernimmt außerdem vollständiges JSON Schema 2020-12 für Tool-Definitionen. JSON Schema ist ein Standardvokabular zur Beschreibung strukturierter Daten, einschließlich Pflichtfeldern, Typen und Validierungsregeln.

Umfangreichere Schemas können präzisere Ein- und Ausgaben beschreiben. Das gibt Clients bessere Informationen, um Aufrufe zu validieren und Schnittstellen zu erstellen. Zugleich verringert es die Abhängigkeit von vage formulierten Tool-Beschreibungen.

Erweiterungen schaffen eine weitere Form architektonischer Trennung. MCP Apps können serverseitig gerenderte Oberflächen bereitstellen, während Tasks längere Vorgänge übernehmen. Diese Funktionen können sich weiterentwickeln, ohne jede Fähigkeit in den Kern des Protokolls zu zwingen.

Ein formaler Lebenszyklus schreibt mindestens 12 Monate zwischen der Abkündigung einer Funktion und ihrer frühestmöglichen Entfernung vor. Das beseitigt den Migrationsaufwand nicht, gibt Implementierern nach diesem klaren Bruch jedoch ein besser planbares Zeitfenster.

Die offizielle TypeScript-Dokumentation zeigt, dass die Migration weiterhin bewusste Arbeit erfordert. Der SDK migration guide erklärt, dass das neue Wire-Format ausdrücklich übernommen werden muss, statt jede bestehende Anwendung stillschweigend zu ändern.

Diese Vorsicht ist angemessen. Eine neue Spezifikation schafft nicht allein durch ihre Veröffentlichung Interoperabilität. Clients, Server, Gateways und SDKs müssen dieselben Details implementieren und sie mit realen Workloads testen.

Dennoch adressiert der Mechanismus eine konkrete Schwäche. Er ersetzt MCP-spezifische Session-Mechanik durch Muster, die Cloud-Teams bereits für gewöhnliche HTTP-Dienste nutzen.

Expliziter Zustand schafft neue Sicherheits- und Zuverlässigkeitsfragen

Zustandsloses MCP beseitigt Infrastruktur-Reibung, verlagert jedoch mehr Verantwortung auf Tool-Design, Autorisierung und Agentenspeicher.

Explizite Handles machen Zustand sichtbar und übertragbar. Diese Vorteile erweitern zugleich die Orte, an denen sensible Kennungen auftauchen können. Ein Handle kann in Chatverläufe, Prompts, Logs, Traces, Zwischenablageinhalte oder Subagenten-Nachrichten gelangen.

Ein Server darf die Kenntnis einer Kennung nicht als ausreichende Autorisierung behandeln. Er sollte bei jedem Aufruf sowohl das Handle als auch die authentifizierte Identität prüfen.

Das ähnelt dem Design vieler Dokument- und Projektdienste. Eine Ressourcen-ID identifiziert ein Objekt, während der aktuelle Autorisierungskontext bestimmt, ob ein Aufrufer es lesen oder ändern darf.

Nicht authentifizierte Dienste stehen vor einem schwierigeren Problem. In diesem Umfeld kann ein nicht vorhersagbares Handle wie ein Bearer-Token funktionieren. Jeder, der es erhält, kann auf den zugrunde liegenden Zustand zugreifen, bis das Handle abläuft.

Die zustandslose Spezifikation empfiehlt für solche Fälle Kennungen mit hoher Entropie und begrenzte Laufzeiten. Diese Empfehlung bleibt Implementierungsleitlinie, da MCP keinen Handle-Typ auf Wire-Ebene definiert.

Dadurch entsteht eine Durchsetzungslücke. Clients können nicht automatisch erkennen, welche zurückgegebenen Zeichenfolgen einen aktiven Zustand repräsentieren. Ein browser_id sieht wie jeder andere Wert aus, sofern Tool-Namen und Beschreibungen seine Rolle nicht vermitteln.

Ein Orchestrator kann daher nicht immer wissen, welche Kennungen eine Kontextkomprimierung überstehen müssen. Zudem könnte es ihm schwerfallen, festzustellen, welche Werte bereinigt werden müssen oder niemals an einen anderen Subagenten weitergegeben werden sollten.

Modelle transportieren routinemäßig Dateipfade, Commit-Hashes, URLs und Transaktionskennungen. Sie können ein Handle dennoch falsch kopieren, weglassen oder verlieren, wenn ein langes Gespräch zusammengefasst wird.

Session-Zustand hatte ähnliche Schwächen. Clients verwendeten uneinheitliche Laufzeiten, und viele stellten Sessions nach Verbindungsabbrüchen nicht wieder her. Das Entfernen von Sessions macht diese Probleme sichtbar, automatisiert Zustandsverwaltung jedoch nicht.

Auch die Bereinigung bleibt ein ungelöstes Detail. Das Ende einer Session bot einst zumindest theoretisch ein Signal zur Freigabe von Ressourcen. Tatsächliche Clients beendeten Sessions jedoch oft zu häufig, zu selten oder nach einem nicht zusammenhängenden Neuladen der Seite.

Explizite Workflows benötigen eigene Richtlinien für Ablauf und Zerstörung. Ein Browser-Dienst könnte close_browser anbieten und zugleich ein Idle-Timeout durchsetzen. Ein Task-Dienst könnte abgeschlossene Ergebnisse für einen definierten Zeitraum aufbewahren.

Abwärtskompatibilität erhöht während der Einführung die operative Komplexität. Bestehende Server, die von Session-IDs abhängen, können nicht einfach die neue Protokollrevision akzeptieren, ohne ihr Zustandsmodell zu ändern.

Clients und SDKs können bei Bedarf eine ältere Revision aushandeln. Das ermöglicht eine schrittweise Migration, schafft jedoch auch zwei Verhaltenspfade, die Entwickler testen müssen.

Einige Fähigkeiten werden unter zustandslosem HTTP weniger direkt. Unaufgeforderte Benachrichtigungen und langlebige, servergesteuerte Interaktionen passen nicht so natürlich zu unabhängigen Requests. Erweiterungen und Listening-Mechanismen müssen diese Arbeit übernehmen.

Es gibt auch keine Garantie, dass jede MCP-Integration allein dadurch effizient wird, dass Sessions verschwinden. Schlecht entworfene Schemas können Kontext verbrauchen. Große Tool-Kataloge können Modelle verwirren. Unklare Beschreibungen können weiterhin falsche Aufrufe auslösen.

Skills und Kommandozeilen-Tools bewahren hier ihre Vorteile. Ein Coding-Agent kann häufig die Hilfeausgabe eines Programms prüfen und ein kurzes Skript schreiben, ohne einen großen entfernten Tool-Katalog laden zu müssen.

Lokale Tools können sensible Daten außerdem auf dem Rechner des Nutzers halten. Eine entfernte MCP-Bereitstellung bringt Authentifizierungs-, Netzwerkexpositions-, Logging- und Verfügbarkeitsfragen mit sich, die lokale Ausführung vermeidet.

Auch Prompt Injection löst MCP nicht. Ein Tool-fähiger Agent kann private Informationen, nicht vertrauenswürdige Eingaben und externe Kommunikation kombinieren, unabhängig davon, ob der Transport zustandsbehaftet ist.

Serverbetreiber müssen Berechtigungen und Ausgaben einschränken. Entwickler von Agenten müssen kontrollieren, welche Tools gemeinsam erscheinen. Nutzer benötigen klare Freigabegrenzen für folgenreiche Aktionen.

Diese Einschränkungen stellen die stärkste Interpretation der Kehrtwende von Anthropic und Simon infrage. Willisons erneutes Interesse bestätigt die Architekturänderung, nicht jede MCP-Implementierung oder jeden vorgeschlagenen Server.

mcp-explorer und datasette-mcp sind nützliche frühe Experimente, weil sie praktische Fragen offenlegen. Können Clients Tools konsistent entdecken? Sind Schemas verständlich? Überstehen Authentifizierung und Zustands-Handles reale Workflows?

Das stärkste Argument für zustandsloses MCP wird aus Interoperabilitätsnachweisen entstehen. Unabhängige Clients sollten sich ohne individuelle Patches mit unabhängigen Servern verbinden, während Betreiber sie mit gewöhnlicher Infrastruktur bereitstellen können sollten.

Bis diese Evidenz wächst, bleibt MCP 2.0 ein besseres Fundament statt eines abgeschlossenen Siegs. Das Protokoll hat eine wesentliche Reibungsquelle beseitigt. Implementierer entscheiden weiterhin, ob die daraus entstehenden Systeme sicher und verständlich bleiben.

Worauf Entwickler nach MCP 2.0 achten sollten

Der nächste Test ist die Einführung über SDKs, reale Server und Clients hinweg – nicht ein weiterer Anstieg von Repository-Zahlen.

Das erste Signal ist die Implementierungsabdeckung für die Revision 2026-07-28. Offizielle SDKs benötigen konsistente Unterstützung für Discovery, Metadaten pro Request, explizite Fähigkeiten, Tasks und Autorisierungsverhalten.

Versionsbezeichnungen allein werden nicht ausreichen. Entwickler sollten Konformitätsergebnisse und sprachübergreifende Tests beobachten. Ein Python-Server, TypeScript-Client und ein verwaltetes Gateway sollten bei denselben Requests und Fehlern übereinstimmen.

Starke SDK-übergreifende Kompatibilität würde das Argument stärken, dass MCP nun eine stabile Grenze für entfernte Tools bietet. Anhaltende Abweichungen würden es schwächen, indem sie Entwickler wieder zu client-spezifischen Adaptern zurückführen.

Das zweite Signal ist, wie Produktionsserver zustandsbehaftete Workflows migrieren. Browser-Automatisierung, Transaktionen, Warenkörbe und langlaufende Rechercheaufträge liefern anspruchsvolle Tests für explizite Handles.

Erfolgreiche Migrationen sollten zuverlässige Bereinigung, Autorisierung pro Request, Handle-Übergabe und Kontextkomprimierung zeigen. Sie sollten zudem dokumentieren, was geschieht, wenn ein Agent eine Kennung verliert oder wiederholt.

Wenn diese Muster wiederverwendbar werden, wird expliziter Zustand wie eine bessere Abstraktion als mehrdeutige Sessions wirken. Wenn jeder Server inkompatible Lebenszyklusregeln erfindet, hat das Protokoll Komplexität lediglich verlagert statt reduziert.

Das dritte Signal ist die Beziehung zwischen MCP und Skills. Agent-Plattformen sollten zeigen, wann sie einen lokalen Befehl, einen von einem Skill geleiteten API-Aufruf oder einen entfernten MCP-Server wählen.

Klare Auswahlregeln würden die engere These stärken. MCP würde gemeinsame entfernte Fähigkeiten bereitstellen, während Skills Anweisungen und lokale Workflows bündeln würden.

Anhaltende Überschneidungen könnten doppelte Wartung verursachen. Tool-Eigentümer bräuchten möglicherweise eine API, CLI, ein Skill-Paket, einen MCP-Server und eine client-spezifische Integration für dieselbe Fähigkeit.

Entwickler sollten diese Doppelung nicht als unvermeidlich betrachten. Ein Skill kann auf einen MCP-Server verweisen, und ein MCP-Server kann eine bestehende API kapseln. Die nützliche Frage lautet, welche Schnittstelle den dauerhaften Vertrag besitzt.

Für Daten-Tools bieten Willisons Experimente einen konkreten Bereich zur Beobachtung. Datasette stellt bereits strukturierte Informationen über Web-APIs bereit. datasette-mcp kann prüfen, ob ein auf Agenten ausgerichteter Vertrag Discovery und sichere Abfragen verbessert.

Teams, die Wissens-Workflows entwickeln, stehen vor einer ähnlichen Wahl. Lokale Dokumente und Notizen gehören häufig in eine private, durchsuchbare Engineering-Wissensdatenbank. Gemeinsame Geschäftssysteme passen möglicherweise besser zu authentifizierten Remote-Tools.

Entscheidend ist, einem Agenten nicht allein deshalb eine uneingeschränkte Sammlung von Tools zu gewähren, weil ein gemeinsames Protokoll die Verbindung erleichtert. Standardisierung reduziert Integrationsaufwand, ersetzt aber kein Berechtigungsdesign.

Die Kehrtwende von Anthropic und Simon Willison ist wertvoll, weil ihr eine Phase echter Skepsis vorausging. MCP gewann nicht durch Branding wieder Aufmerksamkeit. Seine Maintainer beseitigten eine strukturelle Last, auf die Kritiker in produktiv eingesetzten Systemen hinweisen konnten.

So sollte sich ein Protokoll weiterentwickeln. Es sollte Erkenntnisse aus fehlgeschlagenen Annahmen aufnehmen, seine Verantwortlichkeiten eingrenzen und gängige Vorgänge leichter nachvollziehbar machen.

Prüfen Sie in den nächsten drei Monaten die Clients und Server, die Sie tatsächlich nutzen. Kontrollieren Sie, ob sie die finale Revision unterstützen, wie sie Anwendungszustand darstellen und ob ihre Autorisierung jedem Handle folgt.

Vergleichen Sie das Ergebnis anschließend mit der einfachsten Alternative. Wenn ein lokaler Befehl klarer bleibt, behalten Sie ihn bei. Wenn viele Agenten eine gemeinsam verwaltete entfernte Fähigkeit benötigen, testen Sie zustandsloses MCP und dokumentieren Sie, wo Interoperabilität weiterhin scheitert.