| Internet-Draft | MCP Tool Surface Names | May 2026 |
| Morrison | Expires 16 November 2026 | [Page] |
This document requests the establishment of an IANA registry for Model Context Protocol [MCP-SPEC] tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. Existing Morrison- family Internet-Drafts ([ORGALTER]) request IANA registration of specific surface names against a registry that does not yet exist. This document establishes the registry mechanism so that subsequent specifications can register names without restating the registry's structure or registration procedure.¶
The registry uses Specification Required registration with a Designated Expert pool [RFC8126]. Initial contents are the four surface names registered by [ORGALTER]. Vendor-prefix conventions are recommended but not mandated.¶
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 16 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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."¶
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.¶
Existing Morrison-family Internet-Drafts request IANA registration
of specific surface names ([ORGALTER] requests registration of
org_alter_handbook, org_alter_sop_registry,
org_alter_enforcement_gates, and org_alter_ingest). Each such
request currently restates the registry's structure and
registration procedure, on the implicit assumption that a registry
will be established by a future memo.¶
This document is that memo. It establishes the registry, defines the per-entry fields and the registration procedure, and registers the four names from [ORGALTER] as the initial contents.¶
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 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 4.¶
The document that defines the argument schema, the return shape, the authentication scope, and the behavioural semantics of a surface name.¶
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.¶
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.¶
Each registry entry SHALL carry the following fields:¶
| Field | Description |
|---|---|
| Surface name | The textual identifier, in lowercase ASCII, matching the ABNF below. |
| Specification reference | A pointer to the document that specifies the surface's argument schema, return shape, authentication scope, and semantics. |
| Authentication scope | The class of credential the server requires before serving the surface (e.g. member-recognition, trust-tier:engineering, ~handle-signed-token, public). |
| Vendor prefix | The vendor prefix the name falls under, or none for cross-vendor common names. |
| Change controller | The entity authorised to amend or withdraw the registration. |
| Status | One of Active, Provisional, Deprecated, or Withdrawn. |
| First registered | The date the entry first entered the registry. |
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.¶
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.¶
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.¶
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:¶
The proposed surface name conforms to the ABNF in Section 4.2.¶
The Specification Reference is stable and publicly retrievable at the time of registration.¶
The argument schema and return shape described in the Specification Reference are precise enough to enable interoperable client implementations.¶
The authentication scope is well-defined; ambiguous scopes ("authenticated") are returned for clarification.¶
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.¶
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.¶
The following entries are registered as the initial contents of
the registry, in Active status, per the registration requests of
[ORGALTER]:¶
| Surface name | Specification | Auth scope | Vendor prefix | Change controller | Status |
|---|---|---|---|---|---|
org_alter_handbook
|
[ORGALTER] |
member-recognition
|
org_alter_
|
Alter Meridian Pty Ltd | Active |
org_alter_sop_registry
|
[ORGALTER] |
member-recognition
|
org_alter_
|
Alter Meridian Pty Ltd | Active |
org_alter_enforcement_gates
|
[ORGALTER] |
member-recognition
|
org_alter_
|
Alter Meridian Pty Ltd | Active |
org_alter_ingest
|
[ORGALTER] |
member-recognition
|
org_alter_
|
Alter Meridian Pty Ltd | Active |
Subsequent Morrison-family Internet-Drafts that reference further
surface names under the org_alter_ vendor prefix will request
registration against this registry by name; each request will
identify the Specification Reference, authentication scope, and
change controller for the new surface. No registry-structure
amendment is required to admit further entries.¶
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.¶
The DNS substrate of [MCPDNS] enables discovery of MCP servers
for a given ~handle; once a server is discovered, the server's
manifest enumerates the surface names it offers. The registry
ensures that each name in the manifest maps to a unique
specification.¶
A vendor prefix is not formally owned by any registrant; the prefix is a convention. However, 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).¶
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.¶
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.¶
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.¶
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. The Designated Expert's role under Section 6.2 is to reject such squatting requests on first-use evidence. The registry mechanism does not provide cryptographic enforcement of vendor-prefix ownership; the safeguard is procedural.¶
A surface name registered with an authentication scope of public
is invokable by any caller. Operators SHOULD audit their public-
surface registrations periodically and SHOULD NOT register a
surface as public if any future revision is anticipated to
require authentication; demoting a public surface to an
authenticated surface is a breaking change for callers.¶
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 5 of this document.¶
Per-entry fields: Surface name, Specification reference, Authentication scope, Vendor prefix, Change controller, Status, First registered, as defined in Section 4.1 of this document.¶
ABNF for surface names: As defined in Section 4.2 of this document.¶
Initial contents: As defined in Section 6 of this document.¶
Reference: This document.¶
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].¶