Summary

  • Charleston Road Registry's proposed .mcp policy makes four kinds of MCP participation tests for second-level domain eligibility.
  • A proposed .MCP Policy Council would have consent rights over policy amendments, but the public application does not explain how that council is formed or held accountable.

There is a subtle institutional shift inside the .mcp application. The Model Context Protocol is an open technical project. A domain name under .mcp, if the application succeeds, would be allocated under a registry contract. Those systems can support each other, but they do not answer the same question: contributing to, operating with or belonging to a protocol is not automatically the same as earning permission to register a name in a particular namespace.

The public application of Charleston Road Registry Inc. (CRR), Google Registry's legal applicant, proposes four ways to qualify. A registrant could show a documented contribution to official MCP repositories; operate an active, compliant MCP server; own or represent an entry in the official MCP Registry; or be an Agentic AI Foundation (AAIF) member in good standing. CRR says the Registry Operator would verify eligibility with assistance from an .MCP Policy Council. Its response to application question 151 adds that the policy may be amended only with that council's consent.

The proposed boundary is wider than a familiar “use the right suffix” rule. Someone building an MCP client, documentation site, research project or service might need a qualifying status before getting a name. For a server operator, the test is operational. For contributors, it is historical and repository-based. For AAIF members, it is institutional. Those are different kinds of evidence, with different ways to lapse, be disputed or be unavailable to a new participant. The application describes the categories; the public response does not specify the verification thresholds, appeal route or remedy for an erroneous rejection.

That gap matters more because the rulebook has a proposed custodian. The .MCP Policy Council is named in the filing as a participant in enforcement and the body whose consent is needed to amend policy. Yet the public application response does not say who sits on it, how members are appointed or removed, how conflicts are handled, whether affected registrants can appeal, or how its remit relates to MCP's project governance. This is not evidence of capture or bad faith. It is a missing governance specification around a potentially durable gate.

The project record describes a different governance structure. MCP's public governance page lists a Steering Group and Lead, Core and Maintainer roles. It says technical governance is exercised by individuals, not company seats. It does not name an .MCP Policy Council. The records therefore do not justify treating the proposed council as MCP's technical leadership—or assuming the technical project's decisions automatically bind a .mcp registry. A DNS registry can impose and verify contract conditions for the names it sells; that is distinct from deciding who may contribute to MCP, what implementations conform, or how the protocol evolves.

ICANN's process adds another boundary. The 7 October Reveal Day file places five applications in an initial .mcp contention set: CRR, OPENAI OPCO, Radix, ShortDot and Tidal Case. All five public summaries show Active / Pre-Evaluation Processing. Only CRR's summary displays Community in its public tldTypes field. The other four display empty arrays; that is not proof that they lack a community argument. Nor is this set final: ICANN says the APS will not show final contention groups until String Evaluation is complete.

If CRR keeps its community designation and opts in, a later Community Priority Evaluation could affect which applicant has priority for .mcp. The current Applicant Guidebook calls CPE an independent expert assessment of an application seeking priority within string contention. The applicant must first complete relevant evaluation and dispute steps, and proposed Registry Commitments must pass their own evaluation before CPE. A passing community application may prevail over non-community applications in the set; if more than one community application passes, they proceed to auction. CPE uses four criteria and requires 12 of 16 points. It does not decide whether MCP exists as a community: the applicant identifies the community, while CPE decides whether the application earns contention priority. CPE is not a referendum on the legitimacy of MCP's technical institutions.

Note 72 offers a useful question, but not a rule to transplant. Its warning that a mailing list, meeting or policy consensus does not automatically confer ownership was written about RIR authority over number resources. A gTLD registry operates under a different contract and must be able to administer registrations. The relevant test here is narrower: are eligibility decisions bounded, explainable and contestable, and can a participant tell who controls a rule that affects access to names?

The .mcp bid is not yet a delegation and its proposed policy is not an approved right. The separation already visible in the documents is enough to guide due diligence: treat protocol participation and namespace eligibility as distinct; ask which evidence will qualify and how disputes are resolved; identify the body with amendment consent; and do not infer authority over MCP's technical direction from a registry role. If the application advances, transparency around the Council will be as consequential as the eligibility list itself.

Sources