



Network Working Group                                        B. Morrison
Internet-Draft                                    Alter Meridian Pty Ltd
Intended status: Standards Track                             15 May 2026
Expires: 16 November 2026


     An IANA Registry for Model Context Protocol Tool Surface Names
           draft-morrison-mcp-tool-surface-names-registry-00

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 16 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Morrison                Expires 16 November 2026                [Page 1]

Internet-Draft           MCP Tool Surface Names                 May 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.  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.

Table of Contents

   1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Registry Structure  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Per-Entry Fields  . . . . . . . . . . . . . . . . . . . .   4
     4.2.  ABNF for Surface Names  . . . . . . . . . . . . . . . . .   5
   5.  Registration Procedure  . . . . . . . . . . . . . . . . . . .   5
   6.  Initial Registry Contents . . . . . . . . . . . . . . . . . .   6
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .   7
     7.1.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Vendor-Prefix Ownership . . . . . . . . . . . . . . . . .   7
     7.3.  Deprecation and Withdrawal  . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     8.1.  Name Collision  . . . . . . . . . . . . . . . . . . . . .   7
     8.2.  Specification Drift . . . . . . . . . . . . . . . . . . .   8
     8.3.  Vendor-Prefix Squatting . . . . . . . . . . . . . . . . .   8
     8.4.  Public-Surface Caller Confusion . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
     A.1.  draft-morrison-mcp-tool-surface-names-registry-00 . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  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/.




Morrison                Expires 16 November 2026                [Page 2]

Internet-Draft           MCP Tool Surface Names                 May 2026


   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."

2.  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.

   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.

2.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.

3.  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 4.

   Surface Specification  The document that defines the argument schema,




Morrison                Expires 16 November 2026                [Page 3]

Internet-Draft           MCP Tool Surface Names                 May 2026


      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.

4.  Registry Structure

4.1.  Per-Entry Fields

   Each registry entry SHALL carry the following fields:

     +================+=============================================+
     | 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




Morrison                Expires 16 November 2026                [Page 4]

Internet-Draft           MCP Tool Surface Names                 May 2026


   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.

4.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.

   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.

5.  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 4.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.





Morrison                Expires 16 November 2026                [Page 5]

Internet-Draft           MCP Tool Surface Names                 May 2026


   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.

6.  Initial Registry Contents

   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    |Change    |Status|
   |                           |             |           |prefix    |controller|      |
   +===========================+=============+===========+==========+==========+======+
   |org_alter_handbook         |[ORGALTER]   |member-    |org_alter_|Alter     |Active|
   |                           |             |recognition|          |Meridian  |      |
   |                           |             |           |          |Pty Ltd   |      |
   +---------------------------+-------------+-----------+----------+----------+------+
   |org_alter_sop_registry     |[ORGALTER]   |member-    |org_alter_|Alter     |Active|
   |                           |             |recognition|          |Meridian  |      |
   |                           |             |           |          |Pty Ltd   |      |
   +---------------------------+-------------+-----------+----------+----------+------+
   |org_alter_enforcement_gates|[ORGALTER]   |member-    |org_alter_|Alter     |Active|
   |                           |             |recognition|          |Meridian  |      |
   |                           |             |           |          |Pty Ltd   |      |
   +---------------------------+-------------+-----------+----------+----------+------+
   |org_alter_ingest           |[ORGALTER]   |member-    |org_alter_|Alter     |Active|
   |                           |             |recognition|          |Meridian  |      |
   |                           |             |           |          |Pty Ltd   |      |
   +---------------------------+-------------+-----------+----------+----------+------+

                                  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.



Morrison                Expires 16 November 2026                [Page 6]

Internet-Draft           MCP Tool Surface Names                 May 2026


7.  Operational Considerations

7.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.

7.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).

7.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.

8.  Security Considerations

8.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



Morrison                Expires 16 November 2026                [Page 7]

Internet-Draft           MCP Tool Surface Names                 May 2026


   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.

8.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.

8.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.

8.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.

9.  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 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.





Morrison                Expires 16 November 2026                [Page 8]

Internet-Draft           MCP Tool Surface Names                 May 2026


   *  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.

10.  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].

11.  References

11.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/>.

11.2.  Informative References

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.





Morrison                Expires 16 November 2026                [Page 9]

Internet-Draft           MCP Tool Surface Names                 May 2026


   [MCP-SPEC] Model Context Protocol Working Group, "Model Context
              Protocol Specification", 2025,
              <https://modelcontextprotocol.io/specification>.

   [IDPRONOUNS]
              Morrison, B., "Identity Pronouns: A Reference-Axis
              Extension to ~handle Identity Systems", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-identity-
              pronouns/>.

   [ALTERURI] Morrison, B., "The 'alter' URI Scheme for Dispatchable
              ~handle References", 2026,
              <https://datatracker.ietf.org/doc/draft-morrison-alter-
              uri-scheme/>.

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
   Cronulla, NSW
   Australia
   Email: blake@truealter.com





















Morrison                Expires 16 November 2026               [Page 10]
