Network Working Group B. Morrison Internet-Draft Alter Meridian Pty Ltd Intended status: Informational 9 October 2026 Expires: 12 April 2027 An IANA Registry for Model Context Protocol Tool Surface Names draft-morrison-mcp-tool-surface-names-registry-02 Abstract This document requests the establishment of an IANA registry for Model Context Protocol (MCP) tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. This document establishes the registry mechanism so that specifications can register names without restating the registry's structure or registration procedure. The registry uses the Specification Required policy of RFC 8126, with a Designated Expert pool. Initial contents are four surface names drawn from a companion specification of policy provision over MCP, one registered as Active and three as Provisional. Vendor-prefix conventions are recommended but not mandated. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Morrison Expires 12 April 2027 [Page 1] Internet-Draft MCP Tool Surface Names October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Registry Structure . . . . . . . . . . . . . . . . . . . . . 3 3.1. Per-Entry Fields . . . . . . . . . . . . . . . . . . . . 3 3.2. ABNF for Surface Names . . . . . . . . . . . . . . . . . 4 4. Registration Procedure . . . . . . . . . . . . . . . . . . . 5 5. Initial Registry Contents . . . . . . . . . . . . . . . . . . 6 6. Operational Considerations . . . . . . . . . . . . . . . . . 6 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Vendor-Prefix Ownership . . . . . . . . . . . . . . . . . 7 6.3. Deprecation and Withdrawal . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.1. Name Collision . . . . . . . . . . . . . . . . . . . . . 7 7.2. Specification Drift . . . . . . . . . . . . . . . . . . . 8 7.3. Vendor-Prefix Squatting . . . . . . . . . . . . . . . . . 8 7.4. Authentication Changes . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 11. Informative References . . . . . . . . . . . . . . . . . . . 9 Document History . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Model Context Protocol [MCP-SPEC] specifies a wire format for clients (typically agent runtimes) to invoke typed capabilities ("tools") on remote servers. Each tool is addressed by a textual surface name; the server's manifest enumerates the surface names it offers and the JSON Schema of each surface's arguments and return shape. In the absence of a coordinated registry, surface names are chosen ad hoc by server operators. Collisions are common: two operators may both expose a surface named search, with incompatible argument schemas, and a client switching between servers has no machine- readable signal that the two surfaces are not the same capability. Morrison Expires 12 April 2027 [Page 2] Internet-Draft MCP Tool Surface Names October 2026 [ORGALTER] names four typed surfaces, org_alter_handbook, org_alter_sop_registry, org_alter_enforcement_gates, and org_alter_ingest, as illustrative of its reference substrate. It requests no IANA action, and leaves a registry for canonical surface names to a future revision or a companion specification. This document establishes the registry, defines the per-entry fields and the registration procedure, and registers the four names from [ORGALTER] as the initial contents. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [BCP14] when, and only when, they appear in all capitals, as shown here. 2. Terminology Surface Name A textual identifier by which an MCP client invokes a typed capability on an MCP server. Surface names are case- sensitive ASCII strings matching the ABNF in Section 3.2. Surface Specification The document that defines the argument schema, the return shape, the authentication requirements, and the behavioural semantics of a surface name. Operator The entity responsible for a substrate that exposes one or more MCP servers. An operator is identified by a ~handle per [MCPDNS] when the substrate is recognised under the DNS identity protocol. Written as a URI, that handle is an alter: URI as defined in [ALTER-URI], for example alter:~acme. Vendor Prefix A common leading substring shared by surface names operated by a single substrate. org_alter_ is the vendor prefix for the reference substrate operated by Alter Meridian Pty Ltd. 3. Registry Structure 3.1. Per-Entry Fields Each registry entry SHALL carry the following fields: Morrison Expires 12 April 2027 [Page 3] Internet-Draft MCP Tool Surface Names October 2026 +===============+==============================================+ | Field | Description | +===============+==============================================+ | Surface name | The textual identifier, in lowercase ASCII, | | | matching the ABNF below. | +---------------+----------------------------------------------+ | Specification | A pointer to the document that specifies the | | reference | surface's argument schema, return shape, | | | authentication requirements, and semantics. | +---------------+----------------------------------------------+ | Vendor prefix | The vendor prefix the name falls under, or | | | none for cross-vendor common names. | +---------------+----------------------------------------------+ | Change | The entity authorised to amend or withdraw | | controller | the registration. | +---------------+----------------------------------------------+ | Status | One of Active, Provisional, Deprecated, or | | | Withdrawn. | +---------------+----------------------------------------------+ | First | The date the entry first entered the | | registered | registry. | +---------------+----------------------------------------------+ Table 1 The Specification Reference SHOULD be a stable document identifier (an RFC number, a datatracker draft URL, a specification persistent URL). Where the specification is owned by a private substrate operator, the Change Controller field identifies the operator and the Specification Reference points to the operator's published specification. 3.2. ABNF for Surface Names surface-name = name-component *( "_" name-component ) name-component = ALPHA *( ALPHA / DIGIT ) Surface names MUST be lowercase ASCII. Underscores separate components. Hyphens, periods, slashes, and uppercase letters MUST NOT appear. The total length of a surface name MUST NOT exceed 64 octets. Morrison Expires 12 April 2027 [Page 4] Internet-Draft MCP Tool Surface Names October 2026 Vendor prefixes are an organisational convention: a registrant that operates a substrate exposing multiple surfaces SHOULD adopt a stable prefix (e.g. org_alter_, acme_) and register every surface that the substrate exposes under that prefix. Use of a vendor prefix is RECOMMENDED but not required; cross-vendor surfaces (those whose specification is intended for adoption by multiple operators) MAY be registered without a prefix. 4. Registration Procedure Registration in this registry SHALL follow the Specification Required policy of [RFC8126] Section 4.6, with the additional provisions below. The Designated Expert pool, appointed by the IESG, evaluates each registration request against the following criteria: 1. The proposed surface name conforms to the ABNF in Section 3.2. 2. The Specification Reference is stable and publicly retrievable at the time of registration. 3. The argument schema and return shape described in the Specification Reference are precise enough to enable interoperable client implementations. 4. The Specification Reference states the authentication requirements of the surface; a Specification Reference that leaves them unstated is returned for clarification. The registry does not itself record them. 5. The proposed entry does not collide with an existing entry either by exact match or by a vendor-prefix conflict (the proposed name would shadow or be shadowed by an existing entry). The Designated Expert MAY accept, request revision of, or reject a request. Rejected requests are returned with reasons. Accepted requests are entered as Active status when the surface is implemented by a server, and as Provisional status when it is specified but not yet implemented. A registrant MAY request Provisional status pending a stable Specification Reference; provisional entries SHALL be reviewed within twelve months of registration and either promoted to Active, returned to the registrant for revision, or removed. Morrison Expires 12 April 2027 [Page 5] Internet-Draft MCP Tool Surface Names October 2026 5. Initial Registry Contents The following entries, the four surfaces of Section 3.1 of [ORGALTER], are registered as the initial contents of the registry. The Vendor prefix of all four is org_alter_ and the Change controller is Alter Meridian Pty Ltd. The alter_ prefix names the canonical handler of each surface, and a name under org_alter_ is an alias of it. +=============================+===============+=============+ | Surface name | Specification | Status | | | reference | | +=============================+===============+=============+ | org_alter_ingest | [ORGALTER] | Active | +-----------------------------+---------------+-------------+ | org_alter_handbook | [ORGALTER] | Provisional | +-----------------------------+---------------+-------------+ | org_alter_sop_registry | [ORGALTER] | Provisional | +-----------------------------+---------------+-------------+ | org_alter_enforcement_gates | [ORGALTER] | Provisional | +-----------------------------+---------------+-------------+ Table 2 org_alter_ingest is served by a deployed server. The other three are specified in [ORGALTER] and have no deployed implementation yet, so they are registered as Provisional and reviewed under Section 4. Further surface names under the org_alter_ vendor prefix are registered through the procedure of Section 4; each request identifies the Specification Reference and change controller for the new surface. No registry-structure amendment is required to admit further entries. 6. Operational Considerations 6.1. Discovery The registry is informational with respect to discovery: a client that wishes to discover whether a server offers a specific surface SHOULD consult the server's manifest rather than the registry. The registry's role is to ensure that two servers offering the same surface name offer the same typed capability, not to enable discovery of which servers offer a surface. Morrison Expires 12 April 2027 [Page 6] Internet-Draft MCP Tool Surface Names October 2026 The DNS records of [MCPDNS] enable discovery of the MCP server for the domain under which a ~handle is hosted; once a server is discovered, its manifest enumerates the surface names it offers. The registry ensures that each name in the manifest maps to a unique specification. 6.2. Vendor-Prefix Ownership A vendor prefix is not formally owned by any registrant; the prefix is a convention. The Designated Expert SHALL treat first-use of a prefix as a strong signal of intended ownership and SHALL reject subsequent requests under the same prefix from unrelated registrants without prior coordination with the first registrant. Disputes over vendor-prefix ownership are resolved by the Designated Expert with reference to documented first-use evidence (datatracker submission dates, publication dates of the registrant's specifications, operational history). 6.3. Deprecation and Withdrawal An entry MAY be moved to Deprecated status by its Change Controller, in which case the entry remains in the registry as a record but new implementations are advised against it. An entry MAY be moved to Withdrawn status only after a deprecation period of at least twelve months, and only if no known implementations remain. Withdrawn entries SHALL NOT be reissued to a different registrant for at least five years. 7. Security Considerations 7.1. Name Collision A surface name that collides with an existing entry's authenticated specification but offers a different typed capability is a potential vector for cross-server confusion. A client that unconditionally assumes the registry-published specification of a surface name, without verifying that the server's advertised manifest matches that specification, may invoke the surface with arguments that the server interprets differently than the client intends. Implementations SHOULD compare the server's manifest against the registry-published specification at session-bind and SHOULD reject mismatches. Morrison Expires 12 April 2027 [Page 7] Internet-Draft MCP Tool Surface Names October 2026 7.2. Specification Drift The Specification Reference of an entry may evolve over time (e.g. an Internet-Draft progresses through revisions, an RFC is published, an organisational specification is revised). The registry tracks the most recent stable reference. Clients implementing against an earlier revision of a specification SHOULD detect specification- version drift via the server's manifest and SHOULD either upgrade their implementation or refuse to invoke the surface. 7.3. Vendor-Prefix Squatting An adversary that registers entries under a vendor prefix intended by a different operator may induce that operator to choose a different prefix or to coordinate with the squatter. Under Section 6.2, the Designated Expert rejects such squatting requests on first-use evidence. The registry mechanism does not provide cryptographic enforcement of vendor-prefix ownership; the safeguard is procedural. 7.4. Authentication Changes The registry does not record authentication requirements; each Specification Reference does. An operator that changes the authentication requirements of a registered surface breaks callers written against the earlier requirements, and SHOULD publish the change in a revised Specification Reference and move the entry through Deprecated where the change is incompatible. 8. IANA Considerations This document requests that IANA establish a new registry titled "Model Context Protocol Tool Surface Names". * Registry name: Model Context Protocol Tool Surface Names * Registration policy: Specification Required per [RFC8126] Section 4.6, with the Designated Expert criteria of Section 4 of this document. * Per-entry fields: Surface name, Specification reference, Vendor prefix, Change controller, Status, First registered, as defined in Section 3.1 of this document. * ABNF for surface names: As defined in Section 3.2 of this document. * Initial contents: As defined in Section 5 of this document. Morrison Expires 12 April 2027 [Page 8] Internet-Draft MCP Tool Surface Names October 2026 * Reference: This document. 9. Acknowledgements The registry mechanism is informed by the IANA registry-design guidance of [RFC8126] and by the practice of vendor-prefixed header- field registries in HTTP and DNS-RR-type registries. The initial contents are drawn from [ORGALTER]. 10. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", 2026, . [ORGALTER] Morrison, B., "Policy Provision and Governance Inheritance from an Organisational Identity Substrate", 2026, . 11. Informative References [ALTER-URI] Morrison, B., "The 'alter' URI Scheme for Dispatchable ~handle References", 2026, . Morrison Expires 12 April 2027 [Page 9] Internet-Draft MCP Tool Surface Names October 2026 [MCP-SPEC] Agentic AI Foundation, "Model Context Protocol Specification", 2026, . Document History draft-morrison-mcp-tool-surface-names-registry-02 (October 2026): Removes the Authentication scope field from the per-entry fields, and replaces the Public-Surface Caller Confusion section with Authentication Changes. Re-statuses three of the four initial entries as Provisional, because no deployed server implements them. The remaining changes are editorial. * Corrects the account of [ORGALTER] in the Abstract, Section 1 and Section 5, which said it requests IANA registration of its four surface names. Since its revision 01 it requests no IANA action and gives the names as illustrative of its reference substrate. * Updates the title of the [ORGALTER] reference to the one that document now carries. * Names the Agentic AI Foundation as the author of [MCP-SPEC]. * Removes the citations from the Abstract. * Removes the statements about what other drafts assumed and what later drafts will do. Section 5 now points further registrations at Section 4. * States in Section 6.1 that [MCPDNS] discovers the MCP server for the domain under which a ~handle is hosted, where it said for a given ~handle. * Points the Surface Name definition at Section 3.2, where the ABNF is, rather than Section 3, and writes every internal section reference as a cross-reference. * Renames the Change Log appendix to Document History and adds the entry for revision 01. * Notes in the Operator definition that an operator's ~handle, written as a URI, is an alter: URI [ALTER-URI], and adds that informative reference. draft-morrison-mcp-tool-surface-names-registry-01 (August 2026): Morrison Expires 12 April 2027 [Page 10] Internet-Draft MCP Tool Surface Names October 2026 * Changes the intended status to Informational on the Independent Submission stream. * Removes the Status of This Memo section from the body, the author's postal address, and three references the text did not cite. * Gives the field values shared by the four initial entries once, above a two-column table. * Corrects the internal section references after renumbering. draft-morrison-mcp-tool-surface-names-registry-00 (May 2026): * Initial submission. Establishes the registry, defines the registration procedure, and registers the four initial entries from [ORGALTER]. Author's Address Blake Morrison Alter Meridian Pty Ltd Email: blake@truealter.com Morrison Expires 12 April 2027 [Page 11]