Ein Assistent kann sagen, wer er ist, ohne sich zu registrieren
Einen Assistenten zu verbinden bedeutete bisher, dass er sich hier zuerst registriert — und Claude legte bei jeder Verbindung einen neuen Client an. Er kann sich jetzt stattdessen über ein Metadatendokument ausweisen: eine Adresse, die er veröffentlicht und die dieser Server liest, so wie es die MCP-Spezifikation vorzieht. Für Clients, die das nicht können, funktioniert die Registrierung weiterhin. Die Genehmigungsseite sagt nun dazu, wo die Beschreibung eines Clients veröffentlicht ist, und warnt, wenn er nur an ein Programm auf Ihrem eigenen Rechner zurückgeschickt werden kann — denn dort kann jedes Programm darum bitten.
Ein Client kann einem Autorisierungsserver auf drei Wegen sagen, wer er ist: sich registrieren, von Hand eingetragen werden, oder ein Dokument unter einer Adresse veröffentlichen und diese Adresse als Namen benutzen. Den dritten liest dieser Server jetzt.
Was ein Metadatendokument ist
Seine client_id ist eine https-URL. Das Dokument unter dieser URL sagt, wie der Client heißt, wohin er zurückgeschickt werden darf und wahlweise, worum er bittet. Der Server holt es während Ihrer Autorisierung, statt eine eigene Registrierung zu führen. Es ist draft-ietf-oauth-client-id-metadata-document-00 in der Fassung, die die MCP-Autorisierungsspezifikation vom 25.11.2025 daraus macht, und Claude bevorzugt es, sobald ein Server sagt, dass er es unterstützt.
Was es ersetzt
Die dynamische Client-Registrierung (RFC 7591) legt hier bei jeder Verbindung einen Client an. Denselben Assistenten erneut zu verbinden ergab einen weiteren, und so standen fünf Zeilen in der Tabelle, alle „Claude" — keine davon von den anderen zu unterscheiden, und auch nicht von einem Fremden, der sich unter demselben Namen registriert hätte. Ein veröffentlichtes Dokument hat eine Adresse, und die Adresse ist die Identität: was es sagt, kann sich ändern, was es ist, nicht. Die Registrierung funktioniert weiterhin, denn es gibt Clients, die nur das können.
Was der Server holt und was nicht
Eine client_id ist hier eine URL, die ein Fremder übergibt und unser Server dann abruft — eine Server-Side Request Forgery, die nur darauf wartet, schlecht geschrieben zu werden. Also: nur https; ein Pfad, denn ein nackter Origin bezeichnet einen Host und keinen Client, und sonst spräche jeder, der eine Datei im Wurzelverzeichnis einer Domain ablegen kann, für die ganze Domain; kein Fragment und keine Zugangsdaten; die URL in kanonischer Form und im Dokument selbst wiederholt. Weiterleitungen werden nicht gefolgt, die Adresse wird aufgelöst und abgelehnt, wenn sie privat ist, es gibt eine eigene Zeitgrenze innerhalb der, die der Client dem ganzen Endpunkt gibt, eine Obergrenze von 64 KB, und der Körper muss JSON sein, bevor er gelesen wird. Antworten werden höchstens eine Stunde gehalten, Fehlschläge eine Minute — eine client_id, die mit 404 antwortet, macht so nicht aus jedem Knopfdruck einen neuen Abruf.
Was die Genehmigungsseite dazu sagt
Wo die Beschreibung des Clients veröffentlicht ist, und dass sie gerade eben gelesen wurde. Und eine Warnung, wenn jede Adresse, an die er zurückgeschickt werden darf, ein Programm auf Ihrem eigenen Rechner ist: das Dokument veröffentlicht der echte Client, aber um den zurückkommenden Code zu fangen, genügt es, einen Port zu belegen, und keine Seite kann zwei Programme auf Ihrem Rechner auseinanderhalten. Das zu beurteilen bleibt Ihnen.
Weiter: Dokumente aus einem Assistenten heraus konvertieren und Dokumente über eine API konvertieren.