Anthropic Simon-Test legt Reibungen bei benutzerdefinierten MCP-Verbindungen offen

Der Anthropic-Beobachter Simon Willison verband einen benutzerdefinierten MCP-Server mit Claude und ChatGPT, doch das Experiment legte zwei sehr unterschiedliche Einrichtungswege offen. Sein Test vom 29. Juli zeigte, dass Standard-Chatoberflächen von Entwicklern erstellte Tools nutzen können – trotz Produktschranken, Anforderungen an Remote-Hosting und zusätzlichem Autorisierungsaufwand.

Das anthropic simon-Experiment ist wichtig, weil sich das Model Context Protocol über Coding-Agenten und Desktop-Konfigurationsdateien hinausbewegt. MCP, ein offenes Protokoll zur Verbindung von KI-Anwendungen mit externen Tools und Daten, erreicht alltägliche Chatfenster. Das erweitert seine Reichweite, während Einschränkungen auf Produktebene schwerer zu übersehen sind.

Claude präsentiert die Verbindung als benutzerdefinierten Connector. ChatGPT ordnet vergleichbare Funktionen seinem App-System und Entwicklerkontrollen zu. Beide können einen Remote-Server erreichen, doch keiner macht diesen Server zu einem universell portierbaren Plug-in. Das Protokoll standardisiert die Kommunikation, während jeder Host weiterhin Erkennung, Berechtigungen, Freigaben und Verfügbarkeit kontrolliert.

Was Simon Willisons MCP-Test tatsächlich verändert hat

Ein benutzerdefinierter MCP-Server kann nun sowohl Claude als auch ChatGPT bedienen, ohne dass Nutzer ihre üblichen Web-Unterhaltungen verlassen müssen.

Willison dokumentierte den Prozess in einem am 29. Juli 2026 veröffentlichten custom MCP test. Das zentrale Ergebnis war unkompliziert: Ein Entwickler kann einen MCP-Server hosten, ihn bei beiden Diensten registrieren und seine Tools in deren regulären Chatoberflächen bereitstellen.

Dieses Ergebnis unterscheidet das Experiment von früheren MCP-Demonstrationen, die sich auf Claude Code, Desktop-Konfigurationsdateien oder entwicklerorientierte Clients konzentrierten. In diesen Umgebungen waren Tool-Verbindungen bereits vergleichsweise selbstverständlich. Standard-Chatprodukte für Verbraucher fügen eine weitere Ebene aus Kontoregeln und Oberflächenkontrollen hinzu.

Der Server muss aus der Ferne erreichbar sein. Ein lokaler Prozess, der den Standard-Ein- und Ausgabe-Transport verwendet, kann nicht einfach in einer Browsersitzung erscheinen. Der Host benötigt einen über das Internet erreichbaren HTTP-Endpunkt, der die von jedem Client erwarteten MCP-Komponenten implementiert.

Der Fernzugriff verändert das Bereitstellungsmodell. Ein Entwickler konfiguriert nicht länger eine Anwendung, die einen vertrauenswürdigen Prozess auf einem persönlichen Computer startet. Stattdessen betreibt der Entwickler einen Netzwerkdienst, der Transportsicherheit, Identität, Autorisierung, Verfügbarkeit und potenziell mehrere Nutzer handhaben muss.

Claude bezeichnet diese Integrationen als benutzerdefinierte Connectors. Anthropic erklärt, dass sie Claude über Remote-MCP-Server mit gehosteten Tools und Datenquellen verbinden können. Die aktuelle connector guidance nennt Unterstützung durch Claude und Claude Desktop für berechtigte Einzel- und Arbeitsplatzkonten.

ChatGPT beschreibt dieselbe grundlegende Fähigkeit über benutzerdefinierte Apps und MCP-Connectors. Die Oberfläche von OpenAI unterscheidet außerdem zwischen dem Erstellen einer App, ihrem Testen, ihrer Freigabe und ihrer Bereitstellung innerhalb eines Arbeitsbereichs.

Dieser Unterschied in der Benennung ist mehr als kosmetisch. „Connector“ deutet auf eine Brücke zu einem bestehenden Dienst hin. „App“ legt nahe, dass etwas paketiert, geprüft und über eine vom Host kontrollierte Produktoberfläche verteilt wird. MCP kann beide Modelle unterstützen, doch die Bezeichnungen prägen die Erwartungen der Nutzer.

Der Server benötigt außerdem brauchbare Tool-Definitionen. Diese Beschreibungen teilen dem Modell mit, was jedes Tool tut, wann es aufgerufen werden sollte und welche Eingaben es akzeptiert. Ein technisch gültiger Endpunkt kann dennoch schlecht funktionieren, wenn seine Tools sich überschneiden oder unklare Beschreibungen verwenden.

Willisons Test demonstrierte daher Interoperabilität auf Protokollebene, nicht identisches Verhalten über verschiedene Produkte hinweg. Claude und ChatGPT können dieselben grundlegenden Fähigkeiten erkennen. Sie können dennoch Tools unterschiedlich auswählen, unterschiedliche Freigaben anfordern und Ergebnisse über unterschiedliche Oberflächen präsentieren.

Für Entwickler ist die einprägsame Tatsache nicht, dass beide Unternehmen MCP in irgendeiner Form unterstützen. Die wichtige Veränderung besteht darin, dass eine gehostete Implementierung Nutzer nun in beiden gängigen Chatprodukten erreichen kann. Das macht produktübergreifende Tests praktikabel, ohne zwei vollständig getrennte Integrationsprotokolle pflegen zu müssen.

Warum das Anthropic Simon-Ergebnis beide KI-Plattformen unter Druck setzt

MCP verlagert einen Teil des Wettbewerbs von Modellintelligenz hin zur Kontrolle über Tools, Berechtigungen und Verteilung.

Das anthropic simon-Ergebnis setzt Anthropic unter Druck, weil das Unternehmen MCP geschaffen und das Protokoll als offenen Standard gefördert hat. Claude muss ein überzeugender Referenzclient bleiben. Wenn externe Server anderswo vorhersehbarer funktionieren, garantiert die Urheberschaft am Protokoll keine Plattformpräferenz.

OpenAI steht vor dem gegenteiligen Druck. Das Unternehmen hat MCP nicht hervorgebracht, doch ChatGPT spielt als Anwendungsplattform eine enorme Rolle. Entwickler werden erwarten, dass es Integrationen unterstützt, die bereits mit Claude und anderen MCP-Clients funktionieren.

Dadurch entsteht ein klarer Wettbewerb zwischen Portabilität des Protokolls und Plattformkontrolle. Entwickler möchten ein Tool einmal beschreiben und mit kompatiblen Produkten verbinden. Plattformbetreiber möchten entscheiden, welche Konten Server verbinden dürfen, welche Aktionen erlaubt sind und wie riskante Aufrufe geprüft werden.

Claude bietet derzeit ein direktes Konzept für benutzerdefinierte Connectors über mehrere Kontotypen hinweg. Der Einsatz am Arbeitsplatz bringt Administratorkontrollen mit sich, da ein Connector Unternehmensdaten offenlegen oder Aktionen ausführen kann. Ein Eigentümer kann die Verfügbarkeit konfigurieren, während einzelne Nutzer sich weiterhin mit ihren eigenen Berechtigungen authentifizieren.

ChatGPT verfolgt eine ausdrücklichere Bereitstellungsstruktur. OpenAIs aktueller developer mode guide besagt, dass vollständige MCP-Unterstützung im Web für Business- sowie Enterprise- oder Edu-Kunden verfügbar ist. Außerdem beschreibt er eingeschränkteren Lese- und Abrufzugriff für Pro-Nutzer.

Die Unterscheidung wird wichtig, wenn ein Server Schreiboperationen bereitstellt. Das Durchsuchen einer Dokumentensammlung hat ein Risikoprofil. Das Aktualisieren von Kundendatensätzen, Veröffentlichen von Inhalten oder Löschen eines Projekts hat ein anderes.

OpenAI erklärt, dass Schreib- und Änderungsaktionen je nach Berechtigung, Kontext und potenziellen Auswirkungen eine Bestätigung auslösen können. Einige besonders riskante Aktionen können blockiert werden. Administratoren von Arbeitsbereichen kontrollieren zudem, ob eine App vom privaten Test in die freigegebene Verfügbarkeit übergeht.

Anthropic rät Nutzern ebenfalls, Tool-Anfragen zu prüfen und nur die für eine Unterhaltung relevanten Tools zu aktivieren. Diese Warnung verweist auf eine grundlegende Einschränkung agentischer Oberflächen. Eine Anfrage in natürlicher Sprache offenbart nicht immer jede externe Aktion, die ein Modell als notwendig erachten könnte.

Diese Kontrollen schwächen das einfachste Portabilitätsversprechen. Ein Entwickler kann Server, Schemas und die Autorisierungsgrundlage wiederverwenden. Er kann jedoch nicht von übereinstimmendem Zugriff, identischen Nutzerabläufen, gleichem Bestätigungsverhalten oder gleichen Modellentscheidungen ausgehen.

Diese Fragmentierung ist nicht unbedingt ein Protokollfehler. MCP definiert eine gemeinsame Sprache zwischen Clients und Servern. Es verlangt nicht, dass jeder Host dieselben Produktregeln übernimmt.

Dennoch kann Produktreibung darüber entscheiden, ob Protokollkompatibilität in der Praxis zählt. Eine Verbindung, die hinter Administratoreinstellungen verborgen ist, erreicht weniger Nutzer als eine, die über einen persönlichen Einstellungsbildschirm verfügbar ist. Eine schreibgeschützte Implementierung kann keinen Wettbewerber ersetzen, der sorgfältig freigegebene Schreibvorgänge erlaubt.

Die Qualität von Tool-Aufrufen erzeugt zusätzlichen Druck. Das Modell muss das richtige Tool auswählen, gültige Argumente erzeugen, Fehler interpretieren und Ergebnisse vermitteln. Die Unterstützung eines MCP-Transports garantiert nicht, dass die Aufgabe des Nutzers zuverlässig abgeschlossen wird.

Entwickler sollten daher dieselben Prompts auf beiden Plattformen testen. Ein Server kann identische Tools bereitstellen und dennoch unterschiedliche Aufrufmuster erzeugen. Solche Unterschiede können zeigen, ob eine Beschreibung mehrdeutig ist oder ob ein Host strengere Kontrollen anwendet.

Die übergeordnete Wettbewerbsfrage lautet nicht länger, ob Claude oder ChatGPT eine API aufrufen können. Beide Plattformen können das. Entscheidend ist, welche externe Fähigkeiten für gewöhnliche Nutzer verständlich, steuerbar und zuverlässig macht.

Ein Protokoll erzeugt weiterhin zwei Einrichtungserlebnisse

MCP reduziert doppelte Integrationsarbeit, beseitigt jedoch nicht die operativen Schritte rund um eine sichere Verbindung.

Für Claude führt der grundlegende Weg über Settings und Connectors. Ein Nutzer fügt einen benutzerdefinierten Connector hinzu, gibt die Adresse des Remote-Servers an und schließt die Authentifizierung ab, wenn der Server sie erfordert. Eigentümer von Arbeitsbereichen müssen den Connector möglicherweise zunächst aktivieren oder konfigurieren.

Die server documentation von Anthropic verweist Entwickler auf die Autorisierungsspezifikation des Protokolls und Beispiele aus offiziellen SDKs. Sie nennt außerdem Unterstützung für aktuelle Remote-Autorisierungsmuster.

Bei ChatGPT führt der Weg über Apps und erweiterte Einstellungen. Der Nutzer oder Administrator aktiviert Entwicklerzugriff, erstellt eine App, gibt die Remote-MCP-URL ein, wählt eine Authentifizierungsmethode und akzeptiert die Warnung zu einem benutzerdefinierten Server.

Administratoren von Business-Arbeitsbereichen können Apps für ihren Arbeitsbereich erstellen und bereitstellen. Enterprise- und Edu-Umgebungen ergänzen rollenbasierte Kontrollen für Entwickler und Nutzer. Diese Regeln machen die Verbindung zu einem Teil der organisatorischen Governance und nicht nur zu einer persönlichen Konfiguration.

Das gemeinsame technische Zentrum ist ein Remote-MCP-Endpunkt. Moderne Remote-Server verwenden häufig Streamable HTTP, einen Transport, der MCP-Nachrichten über HTTP-Anfragen und Streaming-Antworten überträgt. Dieser Endpunkt muss die Initialisierungs- und Tool-Erkennungsabläufe unterstützen, die kompatible Clients erwarten.

MCP-Nachrichten verwenden JSON-RPC 2.0, ein strukturiertes Format für Anfragen, Ergebnisse, Benachrichtigungen und Fehler. Das Protokoll definiert, wie ein Client Tools erkennt und aufruft. Es definiert nicht die zugrunde liegende Geschäftslogik jedes Tools.

Man stelle sich einen privaten Forschungsserver vor. Er könnte ein Tool zum Durchsuchen gespeicherter Dokumente und ein weiteres zum Abrufen eines vollständigen Datensatzes anbieten. Claude und ChatGPT können diese Definitionen über denselben Endpunkt erkennen.

Der Entwickler muss weiterhin entscheiden, wer welche Datensätze durchsuchen darf. Diese Entscheidung gehört in den Server und seine Autorisierungsschicht. Ein Tool in einer Client-Oberfläche zu verbergen, ersetzt nicht die Durchsetzung des Zugriffs an der Datenquelle.

OAuth wird zentral, wenn der Server nutzerspezifische Daten verarbeitet. Der Client führt den Nutzer durch einen Autorisierungsablauf, erhält ein Zugriffstoken und präsentiert dieses Token beim Aufruf des geschützten MCP-Servers. Der Server validiert das Token anschließend, bevor er Daten zurückgibt.

Die MCP-authorization specification verlangt Metadaten zu geschützten Ressourcen für konforme HTTP-Autorisierungsbereitstellungen. Diese Metadaten teilen einem Client mit, wo sich Autorisierungsdienste befinden. Sie unterstützen die Erkennung, ohne jede Client-Server-Kopplung fest zu codieren.

An diesem Punkt wird aus einem schnellen Proof ein echtes Engineering-Projekt. Der Server benötigt eine stabile HTTPS-Adresse, korrekte Metadaten, die Behandlung von Weiterleitungen, Token-Validierung und passende Scopes. Außerdem benötigt er Fehlermeldungen, die Clients bei fehlgeschlagener Autorisierung interpretieren können.

Die Client-Registrierung kann ein weiteres Kompatibilitätsproblem erzeugen. Einige Systeme unterstützen dynamische Registrierung oder Client-Metadatendokumente. Andere erwarten eine im Voraus erstellte Client-ID. Ein Server, der auf einer Annahme basiert, muss möglicherweise angepasst werden, bevor sich beide Chatprodukte reibungslos authentifizieren können.

Eine praktische Implementierung sollte mit einem eng abgegrenzten, schreibgeschützten Tool beginnen. Beispielsweise könnte ein Team freigegebene Projektnotizen über eine Suchfunktion bereitstellen. Nutzer könnten beide Assistenten bitten, frühere Entscheidungen zu finden, ohne Update- oder Löschrechte zu erhalten.

Dieser Anwendungsfall schafft auch eine natürliche Brücke zu einer persönlichen oder Team-Wissensdatenbank. MCP kann die Zugriffsebene bereitstellen, während das zugrunde liegende System weiterhin für Indexierung, Berechtigungen, Aufbewahrung und Quellenqualität zuständig bleibt.

Sobald der Lesezugriff funktioniert, können Entwickler präzisere Aktionen hinzufügen. Jedes Schreib-Tool sollte einen klaren Zweck und einen begrenzten Umfang haben. „Einen Aufgabenstatus aktualisieren“ lässt sich leichter prüfen als „eine beliebige Projektoperation ausführen“.

Tool-Beschreibungen verdienen dieselbe Sorgfalt wie ein API-Vertrag. Das Modell sieht diese Beschreibungen, wenn es entscheidet, ob es eine Funktion aufruft. Vage Namen erhöhen die Wahrscheinlichkeit einer falschen Auswahl, wiederholter Aufrufe oder unnötigen Datenzugriffs.

Auch Eingabeschemas sollten Mehrdeutigkeit zurückweisen. Ein Tool, das ein Konto ändert, sollte eine stabile Konto-ID verlangen. Es sollte sich nicht allein auf einen Kundennamen stützen, der mehreren Datensätzen entsprechen könnte.

Antworten sollten genügend strukturierte Informationen zurückgeben, damit das Modell erklären kann, was geschehen ist. Ein Schreib-Tool kann das geänderte Objekt, seinen vorherigen Zustand und den neuen Zustand enthalten. Das hilft dem Host, eine aussagekräftige Bestätigung anzuzeigen.

Tests müssen mehr als erfolgreiche Aufrufe abdecken. Entwickler sollten abgelaufene Tokens, entzogene Berechtigungen, nicht verfügbare Abhängigkeiten, fehlerhafte Eingaben und Versuche testen, auf Datensätze anderer Nutzer zuzugreifen. Die beiden Hosts können solche Fehler unterschiedlich darstellen.

Das erklärt, warum das Hinzufügen eines eigenen Servers trotz eines offenen Protokolls langwierig wirken kann. MCP beseitigt eine Kategorie von Integrationsduplikaten. Es beseitigt jedoch nicht Bereitstellung, Identität, Sicherheitsprüfung, Produktkonfiguration oder Qualitätssicherung.

Der eigentliche Zielkonflikt lautet Portabilität versus Vertrauen

Dieselbe Offenheit, die es einem Server ermöglicht, mehrere Assistenten zu erreichen, verschafft diesem Server auch eine privilegierte Position zwischen Nutzern, Modellen und sensiblen Systemen.

Ein eigener MCP-Server kann Eingaben sehen, die über seine Tools gesendet werden. Er kann Inhalte zurückgeben, die das Modell als Kontext behandelt. Wenn er Aktionen bereitstellt, kann er unter der Identität des Nutzers auch externe Daten ändern.

Diese Kombination schafft mehrere Vertrauensgrenzen. Nutzer müssen dem Chat-Anbieter, dem Betreiber des MCP-Servers, dem verbundenen Dienst und der Autorisierungsimplementierung vertrauen. Organisationen müssen zudem den Beschreibungen vertrauen, die das Modellverhalten steuern.

Prompt Injection ist ein großes Anliegen. Eine bösartige Anweisung kann in Daten eingebettet sein, die ein Tool abruft, etwa in einem Dokument, Support-Ticket oder einer Webseite. Das Modell könnte diesen Inhalt als Anweisung statt als nicht vertrauenswürdiges Material interpretieren.

Das Risiko wächst, wenn mehrere Tools verfügbar sind. Abgerufene Inhalte könnten versuchen, das Modell dazu zu bewegen, ein anderes Tool mit sensiblen Argumenten aufzurufen. Ein Lesevorgang kann daher der erste Schritt einer unbeabsichtigten Schreibsequenz werden.

Sowohl Anthropic als auch OpenAI warnen Nutzer davor, nur vertrauenswürdige Server zu verbinden. Dieser Rat ist notwendig, doch Vertrauen ist keine vollständige Sicherheitskontrolle. Selbst ein gut gemeinter Server kann Autorisierungsfehler oder zu weitreichende Aktionen enthalten.

Der Server muss jede Anfrage unabhängig validieren. Er sollte niemals annehmen, dass ein Aufruf sicher ist, nur weil Claude oder ChatGPT ihn erzeugt hat. Bestätigungen durch den Host können Nutzern helfen, ersetzen aber keine serverseitigen Zugriffskontrollen.

Der Umgang mit Tokens erfordert besondere Sorgfalt. Die MCP-Spezifikation verbietet Token-Passthrough, bei dem ein Server ein für einen Dienst bestimmtes Token an einen anderen weiterleitet. Tokens sollten eine festgelegte Zielgruppe haben, und der empfangende Server sollte diese Zielgruppe überprüfen.

Das Prinzip der geringsten Rechte bietet den klarsten Ausgangspunkt. Ein Recherche-Connector sollte Lesezugriff anfordern, bevor er Schreibzugriff verlangt. Ein Kalender-Tool sollte keine Löschrechte verlangen, wenn es lediglich Verfügbarkeiten auflisten muss.

Auch Schreiboperationen profitieren von enger Semantik. Ein Tool namens delete_everything ist offensichtlich gefährlich, doch breit angelegte Verwaltungsfunktionen können ähnliche Risiken hinter freundlicheren Namen verbergen. Jede Aktion sollte einer überprüfbaren Nutzerabsicht entsprechen.

Vorgänge mit hoher Auswirkung sollten Idempotenz unterstützen, damit versehentliche Wiederholungen nicht zu mehreren Änderungen führen. Ein Modell könnte nach einer unklaren Antwort erneut versuchen. Ohne Schutzmaßnahmen könnte eine angeforderte Aufgabe doppelte Datensätze oder Nachrichten erzeugen.

Audit-Logs sind ebenso wichtig. Betreiber müssen wissen, welcher Nutzer einen Aufruf autorisiert hat, welches Tool ausgeführt wurde, welches Objekt geändert wurde und ob der Host eine Bestätigung angezeigt hat. Logs sollten vermeiden, unnötige Prompt-Inhalte oder Geheimnisse aufzubewahren.

Serverbetreiber sollten nutzerbezogene Daten von Steueranweisungen trennen. Tool-Ergebnisse können nicht vertrauenswürdigen Text klar kennzeichnen und, wo möglich, strukturierte Felder zurückgeben. Modelle bleiben anfällig für Manipulation, doch sorgfältiges Output-Design verringert Mehrdeutigkeit.

Auch die Host-Plattformen stehen vor ungelösten Fragen. Ihre Genehmigungsaufforderungen müssen genügend Informationen liefern, damit Nutzer eine Aktion verstehen. Eine allgemeine Aufforderung, „Tool-Zugriff zu erlauben“, bietet wenig Schutz, wenn das Tool mehrere Vorgänge ausführen kann.

Das Verhalten eines Tools kann sich nach der Verbindung ändern. Anthropic weist ausdrücklich darauf hin, dass Serverentwickler Tools ohne Vorwarnung ändern können. Ein Nutzer, der einen harmlosen Such-Connector genehmigt hat, könnte später über denselben Endpunkt auf weiterreichende Funktionen stoßen.

Versionierung und Überprüfung können dieses Risiko verringern. Organisationen können Bereitstellungen an bestimmte Versionen binden, Schemaänderungen überwachen und eine erneute Prüfung verlangen, wenn ein Tool Schreibzugriff erhält. Betreiber öffentlicher Server können Änderungsprotokolle veröffentlichen und Berechtigungsumfänge stabil halten.

Es gibt zudem eine Datenschutzfrage rund um Datenbewegungen. Ein Unternehmen kann seinem Assistenten erlauben, interne Datensätze zu durchsuchen, während es untersagt, dass diese Datensätze einen weiteren Auftragsverarbeiter erreichen. Hosting-Standort und Aufbewahrungsrichtlinie des MCP-Servers werden Teil der Entscheidung.

Eine sichere Bereitstellung benötigt daher mehr als eine gültige Verbindung. Teams sollten Datenkategorien, erlaubte Aktionen, Authentifizierungsbereiche, Aufbewahrungsregeln, Incident-Kontakte und Widerrufsverfahren dokumentieren. Sie sollten außerdem testen, wie jeder Host die Tool-Nutzung meldet.

Die anthropic simon-Demonstration beweist, dass plattformübergreifende Konnektivität möglich ist. Sie beweist nicht, dass jeder erreichbare Server für den Produktionseinsatz geeignet ist. Kompatibilität ist der Beginn der Bewertung, nicht ihr Ende.

Diese Unterscheidung ist für Wissensarbeiter wichtig, die ihren bevorzugten Assistenten auf private Notizen oder Projekthistorien zugreifen lassen möchten. Ein Connector kann das Kopieren zwischen Tools verringern. Er kann jedoch auch den Weg erweitern, über den sensible Kontexte übertragen werden.

Teams, die diesen Zielkonflikt bewerten, sollten mit Informationen beginnen, deren Offenlegung sie unter kontrolliertem Zugriff akzeptieren können. Eine durchsuchbare Sammlung freigegebener Engineering-Dokumentation ist sicherer als ein uneingeschränktes Gateway in jedes interne System.

Anschließend können sie messen, ob der Assistent korrekte Quellen findet, Berechtigungen respektiert und die Tool-Nutzung klar erklärt. Eine Erweiterung sollte Evidenz folgen, nicht allein der Verfügbarkeit eines MCP-Endpunkts.

Worauf das Anthropic-Simon-Experiment als Nächstes hinweist

Der nächste Test für MCP besteht darin, ob plattformübergreifende Server zu alltäglichen Produkten werden statt zu Spezialintegrationen, die über erweiterte Einstellungen zusammengestellt werden.

Das erste Signal ist die Annäherung bei der Remote-Autorisierung. Claude und ChatGPT müssen Nutzer sicher verbinden, ohne dass für jede Kombination eigene Registrierungsarbeit erforderlich ist. Eine breitere Akzeptanz wird zunehmen, wenn eine standardkonforme OAuth-Bereitstellung bei beiden zuverlässig funktioniert.

Bleibt die Autorisierung voller client-spezifischer Ausnahmen, schwächt das den Portabilitätsanspruch. Entwickler werden weiterhin Teile des Servers wiederverwenden, aber getrennte Einrichtungsanleitungen, Metadaten und Fehlerbehebungspfade pflegen.

Die stärksten Belege werden von gewöhnlichen Diensten kommen, die einen Remote-Endpunkt mit geprüften Anweisungen für mehrere Assistenten veröffentlichen. Diese Dienste sollten nicht verlangen, dass Nutzer langlebige API-Schlüssel in Chat-Einstellungen einfügen. Browserbasierte Einwilligung sollte enge, widerrufbare Berechtigungsumfänge gewähren.

Das zweite Signal ist, wie OpenAI den vollständigen MCP-Zugriff erweitert. Die aktuelle Dokumentation unterscheidet zwischen vollständiger Unterstützung für verwaltete Arbeitsplatzkonten und eingeschränkteren Pro-Funktionen. Ein breiterer Weg für Privatnutzer würde Claudes Erfahrung mit eigenen Connectors direkt unter Druck setzen.

Eine anhaltende Betonung der Bereitstellung durch Administratoren würde auf eine andere Strategie hindeuten. ChatGPT Apps würden vor allem als gesteuerte Arbeitsplatzsoftware funktionieren, während Claude einen direkteren Weg für individuelles Experimentieren behalten könnte.

Keine der beiden Richtungen ist automatisch besser. Unternehmen benötigen häufig Genehmigung, Nachvollziehbarkeit und Rollensteuerung. Unabhängige Entwickler schätzen einen kurzen Weg von einem bereitgestellten Server zu einer funktionierenden Unterhaltung.

Das dritte Signal ist, wie beide Plattformen mit Schreibaktionen umgehen. Suche und Abruf liefern anschauliche Demonstrationen, doch Aktionen entscheiden darüber, ob MCP zu einer echten Anwendungsebene wird. Sie schaffen zugleich die schwierigsten Sicherheits- und Schnittstellenprobleme.

Achten Sie auf klarere Berechtigungszusammenfassungen, Aktionsvorschauen, Bestätigungsrichtlinien und Audit-Aufzeichnungen. Ein Host, der externe Auswirkungen gut erklärt, kann Schreib-Tools nutzbarer machen, ohne so zu tun, als seien sie risikofrei.

Entwickler sollten außerdem beobachten, ob Hosts bessere Diagnosen bereitstellen. Verbindungsfehler fassen oft mehrere mögliche Ursachen in einem Fehler zusammen. Das Problem könnte Transportaushandlung, Autorisierungsmetadaten, Redirect-Konfiguration, Token-Zielgruppe oder Tool-Schema-Validierung betreffen.

Bessere Diagnosen würden den Weg von einem funktionierenden lokalen Server zu einer zuverlässigen Remote-Integration verkürzen. Sie würden außerdem den Druck auf Serverbetreiber mindern, unterschiedliche Erwartungen der Hosts rückentwickeln zu müssen.

Registry- und Discovery-Systeme stellen eine weitere wichtige Ebene dar. Ein offenes Protokoll sagt Nutzern nicht, welche Server vertrauenswürdig sind. Kuratierte Verzeichnisse können helfen, geben Plattformbetreibern jedoch auch einen weiteren Kontrollpunkt.

Ein Server, der von einem Host gelistet wird, kann bei einem anderen weiterhin eine manuelle, eigene Verbindung bleiben. Entwickler stehen dann vor einem Vertriebsproblem, selbst wenn ihre Implementierung portabel ist. Prüfungszeiträume und Listungsregeln können zu Wettbewerbsdifferenzierern werden.

Nutzer sollten daher Serverkompatibilität von Serververfügbarkeit unterscheiden. Ein Dienst kann technisch mit Claude und ChatGPT funktionieren, während er weiterhin schwer auffindbar oder durch Workspace-Richtlinien eingeschränkt ist.

Dieselbe Unterscheidung gilt für die Schnittstellenunterstützung. MCP Apps können in kompatiblen Hosts interaktive Schnittstellen zurückgeben, während einfache Tool-Server hauptsächlich strukturierte Daten und Text austauschen. Unterschiedliche Unterstützungsstufen können eine Integration reichhaltiger wirken lassen, obwohl sie dasselbe zugrunde liegende Protokoll verwendet.

Für Entwickler ist die unmittelbare Strategie konservativ. Hosten Sie einen standardkonformen Remote-Server, beginnen Sie mit einem eng abgegrenzten Lese-Tool und testen Sie identische Prompts in beiden Produkten. Halten Sie jeden Unterschied bei Authentifizierung, Discovery, Aufruf und Fehlerbehandlung fest.

Führen Sie anschließend eine begrenzte Schreibaktion hinter ausdrücklicher Autorisierung ein. Bestätigen Sie, dass Wiederholungsversuche keine Änderungen duplizieren und dass der Widerruf funktioniert. Prüfen Sie genau, was jede Plattform anzeigt, bevor die Aktion ausgeführt wird.

Für Organisationen sollte die Entscheidung mit dem Workflow beginnen, nicht mit Begeisterung für MCP. Identifizieren Sie eine wiederkehrende Aufgabe, bei der chatbasierter Zugriff tatsächlichen Wechsel- oder Suchaufwand verringert. Definieren Sie anschließend den kleinsten Daten- und Aktionsumfang, der für ihre Erledigung erforderlich ist.

Ein guter Kandidat könnte freigegebene technische Dokumente durchsuchen und Quelllinks zurückgeben. Ein anderer könnte ein Projektupdate entwerfen, ohne es zu veröffentlichen. Beide schaffen Mehrwert und halten endgültige Änderungen unter menschlicher Kontrolle.

Die Suchanfrage „anthropic simon“ wird vermutlich Leser anziehen, die nach Simon Willisons spezifischem Experiment suchen. Ihr nachhaltiger Wert reicht jedoch über die Abfolge der Einrichtung hinaus. Der Test zeigt, wo die Standardisierung des Protokolls endet und die Plattformrichtlinien beginnen.

MCP hat eine wichtige Grenze überschritten und ist in den Standardoberflächen von Claude und ChatGPT angekommen. Die nächste Frage lautet, ob das Verbinden eines vertrauenswürdigen Servers für gewöhnliche Nutzer unkompliziert, vorhersehbar und sichtbar wird.

Entwickler können schon jetzt helfen, diese Frage zu beantworten. Wählen Sie einen Workflow mit geringem Risiko, bauen Sie einen Remote-Endpunkt mit eng begrenzten Berechtigungen und vergleichen Sie beide Hosts mit denselben Test-Prompts. Die Unterschiede werden zeigen, ob MCP praktische Portabilität bietet oder lediglich eine gemeinsame technische Grundlage.