Zusammenfassung

  • Charleston Road Registry würde die Registrierung einer .mcp-Domain an vier nachweisbare Formen der MCP-Teilnahme knüpfen.
  • Ein .MCP Policy Council soll Änderungen der Regeln zustimmen; öffentlich ist aber nicht festgelegt, wie der Rat zusammengesetzt wird oder wie Betroffene Entscheidungen anfechten können.

Ein offenes Protokoll und ein Domain-Namensraum sind unterschiedliche Institutionen. Das Model Context Protocol ist ein technisches Projekt. Sollte .mcp delegiert werden, verwaltete ein Register die Namen auf Grundlage eines Vertrags. Die beiden Ebenen können einander unterstützen; daraus folgt aber nicht, dass die Teilnahme am Protokoll automatisch zur Registrierung in einem bestimmten Namensraum berechtigt.

Der Antragsteller Charleston Road Registry Inc. (CRR), die rechtliche Antragstellerin von Google Registry, schlägt vier Wege zur Zulassung vor: dokumentierte Beiträge zu offiziellen MCP-Repositories; der Betrieb eines aktiven, regelkonformen MCP-Servers; das Eigentum an oder die autorisierte Vertretung eines Eintrags im offiziellen MCP Registry; oder eine Mitgliedschaft in gutem Stand bei der Agentic AI Foundation (AAIF). Laut Antrag soll der Registerbetreiber diese Bedingungen mit Unterstützung eines .MCP Policy Council prüfen. In der Antwort auf Frage 151 heißt es außerdem, die Richtlinie dürfe nur mit Zustimmung des Rats geändert werden.

Die vier Kategorien prüfen verschiedene Beziehungen. Ein Repository-Beitrag ist historisch dokumentiert, ein Serverbetrieb muss aktuell sein, ein Registry-Eintrag betrifft Vertretungsbefugnis, und die AAIF-Mitgliedschaft ist eine institutionelle Verbindung. Neue Projektteilnehmer, Maintainer, Anbieter und Mitgliederorganisationen können unterschiedliche Nachweise erbringen und unterschiedlich leicht Einspruch erheben. Der Antrag benennt die Kategorien, veröffentlicht aber weder genaue Nachweisschwellen noch den Umgang mit lückenhaften Datensätzen oder ein Verfahren gegen eine Ablehnung.

Auch die Stelle, die über den Regelrahmen mitbestimmt, bleibt unklar. Der .MCP Policy Council soll bei der Prüfung helfen und muss Regeländerungen zustimmen. Die öffentliche Antwort erläutert nicht, wer seine Mitglieder ernennt oder abberuft, wie lange sie im Amt sind, welche Regeln für Interessenkonflikte gelten, ob abgelehnte Antragsteller Einspruch erheben können oder wie der Rat formal mit der technischen MCP-Governance verbunden ist. Diese Lücken beweisen weder Vereinnahmung noch böse Absicht. Sie lassen jedoch offen, wer für eine möglicherweise dauerhafte Zugangsschranke rechenschaftspflichtig wäre.

Die öffentlich beschriebene Projekt-Governance von MCP ist eine andere. Die offizielle Seite nennt eine Steering Group sowie die Rollen Lead, Core und Maintainer. Technische Governance werde von Einzelpersonen ausgeübt; Unternehmenssitze gebe es nicht. Einen .MCP Policy Council nennt die Seite nicht. Deshalb lässt sich der vorgeschlagene Rat nicht mit der technischen Leitung des Projekts gleichsetzen. Ebenso wenig ist belegt, dass Projektentscheidungen das Domainregister automatisch binden. Ein Register kann vertragliche Voraussetzungen für seine Namen verwalten. Das ist etwas anderes als zu bestimmen, wer zum MCP beitragen darf, welche Implementierung konform ist oder wie sich das Protokoll weiterentwickelt.

Auch den ICANN-Zeitplan gilt es sauber einzuordnen. Die am 7. Oktober veröffentlichte Reveal-Day-Datei führt fünf Bewerbungen in einer anfänglichen .mcp-Konkurrenzgruppe: CRR, OPENAI OPCO, Radix, ShortDot und Tidal Case. Alle fünf öffentlichen Kurzprofile zeigen Active / Pre-Evaluation Processing. Nur bei CRR steht im öffentlichen Feld tldTypes der Wert Community. Die vier leeren Felder beweisen nicht, dass diese Bewerber keinen Community-Ansatz verfolgen. ICANN veröffentlicht die Konkurrenzgruppen im APS erst nach Abschluss der String Evaluation als endgültig.

Behält CRR die Community-Kennzeichnung bei und nimmt an einer späteren Community Priority Evaluation (CPE) teil, kann das Ergebnis die Priorität innerhalb der Gruppe beeinflussen. Das aktuelle Applicant Guidebook beschreibt CPE als unabhängige Expertenbewertung für die Priorität in einer Konkurrenzgruppe. Zuvor müssen die einschlägigen Bewertungs-, Einspruchs- und Beschwerdeverfahren abgeschlossen sein; vorgeschlagene Registry Commitments werden separat geprüft. Eine erfolgreiche Community-Bewerbung kann Vorrang vor Bewerbungen ohne Community-Status erhalten. Bestehen mehrere Community-Bewerbungen, folgt eine Auktion.

Vier Kriterien ergeben zusammen 16 Punkte; zum Bestehen sind 12 nötig. Das Handbuch trennt ausdrücklich die Existenz einer Community von der Frage nach Priorität: Der Bewerber benennt die Community, CPE beurteilt den Vorrang des Antrags. CPE ist kein Votum über die Legitimität der technischen MCP-Institutionen.

Note 72 bietet einen Denkansatz, aber keine übertragbare Rechtsregel. Der Hinweis, dass Mailingliste, Treffen oder politischer Konsens für sich allein kein Eigentum oder Mandat begründen, bezieht sich auf die Befugnisse regionaler Internet-Registries für Nummernressourcen. Ein generisches Top-Level-Domain-Register arbeitet unter einem anderen Vertrag und muss Registrierungen verwalten. Hier lautet die engere Frage: Sind die Kriterien begrenzt, Entscheidungen begründet und anfechtbar, und wissen Betroffene, wer sie ändern darf?

.mcp ist noch nicht delegiert; die vorgeschlagene Richtlinie ist nicht genehmigt. Trotzdem sollte die Prüfung bereits jetzt vier Dinge auseinanderhalten: Protokollteilnahme und Domainzulassung, Nachweis und Rechtsbehelf, Registerentscheidung und technische Anerkennung. Falls das Verfahren weitergeht, muss klar werden, wer den Rat bestellt und kontrolliert. Seine Satzung wird ebenso wichtig sein wie die Liste der vier Zugangskategorien.

Quellen