An IANA Registry for Model Context Protocol Tool Surface Names
draft-morrison-mcp-tool-surface-names-registry-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Blake Morrison | ||
| Last updated | 2026-08-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-morrison-mcp-tool-surface-names-registry-01
Network Working Group B. Morrison
Internet-Draft Alter Meridian Pty Ltd
Intended status: Informational 9 August 2026
Expires: 10 February 2027
An IANA Registry for Model Context Protocol Tool Surface Names
draft-morrison-mcp-tool-surface-names-registry-01
Abstract
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.
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 10 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Morrison Expires 10 February 2027 [Page 1]
Internet-Draft MCP Tool Surface Names August 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 . . . . . . . . . . . . . . . . . . . 7
7.3. Vendor-Prefix Squatting . . . . . . . . . . . . . . . . . 8
7.4. Public-Surface Caller Confusion . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9
A.1. draft-morrison-mcp-tool-surface-names-registry-00 . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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 10 February 2027 [Page 2]
Internet-Draft MCP Tool Surface Names August 2026
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.
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 [RFC2119] [RFC8174] 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.
Surface Specification The document that defines the argument schema,
the return shape, the authentication scope, 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.
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 10 February 2027 [Page 3]
Internet-Draft MCP Tool Surface Names August 2026
+================+=============================================+
| Field | Description |
+================+=============================================+
| Surface name | The textual identifier, in lowercase ASCII, |
| | matching the ABNF below. |
+----------------+---------------------------------------------+
| Specification | A pointer to the document that specifies |
| reference | the surface's argument schema, return |
| | shape, authentication scope, and semantics. |
+----------------+---------------------------------------------+
| Authentication | The class of credential the server requires |
| scope | 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 | 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 10 February 2027 [Page 4]
Internet-Draft MCP Tool Surface Names August 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 authentication scope is well-defined; ambiguous scopes
("authenticated") are returned for clarification.
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.
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 10 February 2027 [Page 5]
Internet-Draft MCP Tool Surface Names August 2026
5. Initial Registry Contents
The following entries are registered as the initial contents of the
registry, per the registration requests of [ORGALTER]. All four
entries share the same values for the remaining registry fields. The
Authentication scope is member-recognition, the Vendor prefix is
org_alter_, the Change controller is Alter Meridian Pty Ltd, and the
Status is Active.
+=============================+=========================+
| Surface name | Specification reference |
+=============================+=========================+
| org_alter_handbook | [ORGALTER] |
+-----------------------------+-------------------------+
| org_alter_sop_registry | [ORGALTER] |
+-----------------------------+-------------------------+
| org_alter_enforcement_gates | [ORGALTER] |
+-----------------------------+-------------------------+
| org_alter_ingest | [ORGALTER] |
+-----------------------------+-------------------------+
Table 2
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.
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.
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.
Morrison Expires 10 February 2027 [Page 6]
Internet-Draft MCP Tool Surface Names August 2026
6.2. Vendor-Prefix Ownership
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).
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.
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.
Morrison Expires 10 February 2027 [Page 7]
Internet-Draft MCP Tool Surface Names August 2026
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. 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.
7.4. Public-Surface Caller Confusion
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.
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,
Authentication scope, 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.
* 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. References
Morrison Expires 10 February 2027 [Page 8]
Internet-Draft MCP Tool Surface Names August 2026
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[MCPDNS] Morrison, B., "Discovery of Model Context Protocol Servers
via DNS TXT Records", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
discovery/>.
[ORGALTER] Morrison, B., "Org Alter Policy Provision over MCP", 2026,
<https://datatracker.ietf.org/doc/draft-morrison-org-
alter-policy-provision/>.
10.2. Informative References
[MCP-SPEC] Model Context Protocol Working Group, "Model Context
Protocol Specification", 2025,
<https://modelcontextprotocol.io/specification>.
Appendix A. Change Log
A.1. draft-morrison-mcp-tool-surface-names-registry-00
* 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 10 February 2027 [Page 9]