The "mcp" URI Scheme and MCP Server Discovery Mechanism
draft-serra-mcp-discovery-uri-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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | marco serra | ||
| Last updated | 2026-03-25 | ||
| RFC stream | (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-serra-mcp-discovery-uri-01
Internet-Draft M. Serra
draft-serra-mcp-discovery-uri-01 Mumble Group
Intended status: Standards Track March 25, 2026
Expires: September 25, 2026
The "mcp" URI Scheme and MCP Server Discovery Mechanism
Abstract
The Model Context Protocol (MCP) defines a standard interface for
AI agents to connect to external tools and services. However, no
standard mechanism exists for an AI agent to autonomously discover
which web domains expose an MCP server.
This document defines: (1) the "mcp" URI scheme, a machine-to-
machine identifier for publicly reachable MCP servers; (2) a
discovery convention based on the well-known URI
"/.well-known/mcp-server" as defined in RFC 8615; (3) a fallback
discovery mechanism using DNS TXT records.
This specification does not define the MCP protocol itself, nor
authentication between agent and server. Those are covered by the
MCP specification and OAuth 2.1 respectively.
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 September 25, 2026.
Copyright Notice
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.
Table of Contents
1. Introduction
1.1. Requirements Language
1.2. Out of Scope
1.3. Relationship to Other Work
2. Terminology
3. The "mcp" URI Scheme
3.1. Purpose
3.2. Syntax
3.3. Examples
4. MCP Server Discovery
4.1. Discovery Sequence
4.2. Priority
5. DNS TXT Record Format
5.1. Syntax
5.2. Fields
5.3. Limitations
6. The MCP Server Manifest
6.1. Format
6.2. Required Fields
6.3. Recommended Fields
6.4. Optional Fields
6.5. Minimal Example
6.6. Full Example
6.7. HTTP Response Requirements
7. Reference Implementation
7.1. Live Endpoint
7.2. Verification
8. Security Considerations
8.1. Manifest Spoofing
8.2. DNS Hijacking
8.3. Rate Limiting
8.4. Sensitive Data
9. IANA Considerations
9.1. URI Scheme Registration
9.2. Well-Known URI Registration
10. References
10.1. Normative References
10.2. Informative References
Author's Address
1. Introduction
The Model Context Protocol [MCP-SPEC] has seen rapid adoption since
its publication in November 2024. Thousands of MCP servers are
publicly available, yet there is no standard way for an AI agent to
discover them autonomously starting from a web domain.
Current approaches rely on manual configuration or voluntary
registration in centralized directories. These approaches fail to
cover the long tail of MCP servers and require prior human knowledge
of each server's existence and URL.
This document proposes a lightweight, decentralized discovery
mechanism that allows any MCP client to determine whether a given
web domain exposes an MCP server, using only standard HTTPS requests
and DNS queries -- without relying on any central registry or prior
configuration.
The analogy is instructive: before web crawlers, websites existed
but were invisible to automated discovery. The introduction of HTTP
as a standard scheme, combined with crawlers that followed links,
created the navigable web. This document proposes the equivalent
infrastructure for the MCP ecosystem.
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.
1.2. Out of Scope
This document does NOT define:
o The MCP protocol itself (defined in [MCP-SPEC])
o Authentication between MCP clients and servers (OAuth 2.1)
o The format of MCP tools, resources, or prompts ([MCP-SPEC])
o Discovery of MCP servers on private networks or intranets
o A crawling or indexing infrastructure (implementation concern)
1.3. Relationship to Other Work
The MCP community has independently explored similar ideas.
SEP-1649 [SEP-1649], authored by maintainers of the MCP
specification, proposes a "/.well-known/mcp.json" endpoint for
server card discovery within the MCP ecosystem. That proposal
explicitly notes the need to register the well-known suffix with
IANA per RFC 8615 once approved.
This document addresses the same discovery problem but approaches
it from the IETF standards track, defining a formal URI scheme
("mcp://") and requesting the necessary IANA registrations through
the established process. The authors welcome coordination with
the MCP specification maintainers to align the well-known path
name and manifest schema across both efforts.
The key difference is scope: SEP-1649 focuses on discovery within
an already-established MCP connection context; this document focuses
on pre-connection discovery starting from a bare domain name, as
required for autonomous agent operation and web-scale crawling.
2. Terminology
MCP Server: A service exposing tools, resources, and/or prompts
via the Model Context Protocol [MCP-SPEC].
MCP Client: An AI agent or application that connects to MCP
Servers to invoke tools and retrieve resources.
MCP URI: A URI using the "mcp" scheme as defined in Section 3 of
this document, identifying a publicly reachable MCP Server.
Manifest: The JSON document returned at /.well-known/mcp-server,
as defined in Section 6 of this document.
Discovery: The process by which an MCP Client determines the
endpoint URL of an MCP Server starting from a domain name alone.
3. The "mcp" URI Scheme
3.1. Purpose
The "mcp" URI scheme identifies a publicly reachable MCP Server
associated with a web domain. It is intended for use by AI agents
and automated crawlers, not by human users or web browsers.
3.2. Syntax
The syntax of an MCP URI is defined using ABNF [RFC5234]:
mcp-URI = "mcp://" authority path-abempty [ "?" query ]
authority = [ userinfo "@" ] host [ ":" port ]
host = IP-literal / IPv4address / reg-name
reg-name = *( unreserved / pct-encoded / sub-delims )
path-abempty = *( "/" segment )
segment = *pchar
query = *( pchar / "/" / "?" )
Where "userinfo", "IP-literal", "IPv4address", "unreserved",
"pct-encoded", "sub-delims", and "pchar" are as defined in
[RFC3986].
3.3. Examples
Valid MCP URIs:
mcp://example.com
mcp://api.example.com
mcp://example.com/shop
mcp://example.com:8080
Invalid MCP URIs:
mcp:// (missing host)
mcp:example.com (missing //)
4. MCP Server Discovery
4.1. Discovery Sequence
Upon resolving an MCP URI, clients MUST attempt discovery in the
following order:
Step 1 -- Well-Known URI (REQUIRED)
The client MUST perform an HTTP GET request to:
https://{host}/.well-known/mcp-server
with the header:
Accept: application/json
If the server responds with HTTP 200 and a valid JSON Manifest
(Section 6), the client MUST use the endpoint in the Manifest.
If the server responds with HTTP 301 or 302, the client MUST follow
the redirect, up to a maximum of two redirect levels.
If the server responds with HTTP 404, or the request times out
after 5 seconds, the client MUST proceed to Step 2.
Step 2 -- DNS TXT Record (FALLBACK)
The client MUST query:
_mcp.{host} IN TXT
If a TXT record is present containing "v=mcp1", the client MUST
extract the endpoint URL from the "endpoint" field and use it.
If no such record exists, the client MUST proceed to Step 3.
Step 3 -- Direct Endpoint (LAST RESORT)
The client MAY attempt a direct MCP handshake at:
https://{host}/mcp
If the handshake succeeds, the client MAY use this endpoint.
If it fails, the client MUST report that no MCP server was found.
4.2. Priority
Clients MUST prefer the well-known URI over DNS TXT records because
HTTPS provides domain authenticity guarantees that unsigned DNS
records do not.
5. DNS TXT Record Format
5.1. Syntax
_mcp.{domain} IN TXT "v=mcp1; endpoint={url}[; auth={type}]"
5.2. Fields
+------------+-------------+--------------------------------+
| Field | Requirement | Description |
+------------+-------------+--------------------------------+
| v=mcp1 | MUST | Version discriminator |
| endpoint= | MUST | URL of the MCP endpoint |
| auth= | SHOULD | none, apikey, or oauth2 |
+------------+-------------+--------------------------------+
5.3. Limitations
DNS TXT records are limited to 255 characters per string. For
complete manifests, operators SHOULD use the well-known URI
mechanism (Section 4.1).
6. The MCP Server Manifest
6.1. Format
The Manifest is a JSON document [RFC8259] returned at the path
/.well-known/mcp-server.
6.2. Required Fields (MUST)
+-------------+---------+---------------------------------------+
| Field | Type | Description |
+-------------+---------+---------------------------------------+
| mcp_version | string | MCP spec version (e.g. "2025-06-18") |
| name | string | Human-readable server name |
| endpoint | string | URL of the MCP endpoint |
| transport | string | "http" or "stdio" |
+-------------+---------+---------------------------------------+
6.3. Recommended Fields (SHOULD)
+--------------+---------+--------------------------------------+
| Field | Type | Description |
+--------------+---------+--------------------------------------+
| description | string | Natural language description |
| auth | object | Authentication requirements |
| capabilities | array | ["tools", "resources", "prompts"] |
+--------------+---------+--------------------------------------+
6.4. Optional Fields (MAY)
+--------------+---------+--------------------------------------+
| Field | Type | Description |
+--------------+---------+--------------------------------------+
| categories | array | Semantic categories |
| languages | array | ISO 639-1 language codes |
| coverage | string | ISO 3166-1 country code |
| contact | string | Contact email or URL |
| docs | string | Documentation URL |
| last_updated | string | ISO 8601 timestamp |
| crawl | boolean | false to opt out of indexing |
+--------------+---------+--------------------------------------+
6.5. Minimal Example
{
"mcp_version": "2025-06-18",
"name": "Example MCP Server",
"endpoint": "https://example.com/mcp",
"transport": "http"
}
6.6. Full Example
{
"mcp_version": "2025-06-18",
"name": "Example MCP Server",
"description": "Product catalog and inventory",
"endpoint": "https://example.com/mcp",
"transport": "http",
"auth": { "type": "oauth2",
"discovery": "https://example.com/.well-known/
oauth-protected-resource" },
"capabilities": ["tools", "resources", "prompts"],
"categories": ["e-commerce", "hardware"],
"languages": ["en", "it"],
"coverage": "IT",
"last_updated": "2026-03-25T00:00:00Z",
"contact": "api@example.com",
"docs": "https://example.com/mcp/docs",
"crawl": true
}
6.7. HTTP Response Requirements
Servers MUST respond with:
HTTP/1.1 200 OK
Content-Type: application/json
Servers SHOULD include:
Cache-Control: max-age=3600
7. Reference Implementation
A live reference implementation of this specification is available
at [MCPSTANDARD]. The implementation demonstrates all three
discovery mechanisms defined in this document and serves as a
validation target for client implementations.
7.1. Live Endpoint
The reference implementation exposes a valid Manifest at:
https://mcpstandard.dev/.well-known/mcp-server
This endpoint returns a JSON document conforming to the schema
defined in Section 6 and can be used to verify client
implementations of the discovery sequence defined in Section 4.
To resolve the reference implementation using the mcp:// scheme:
mcp://mcpstandard.dev
Clients implementing this specification SHOULD test against this
endpoint before deployment.
7.2. Verification
The manifest served at the reference implementation can be fetched
and verified with standard HTTP tooling:
GET https://mcpstandard.dev/.well-known/mcp-server
Accept: application/json
Expected response (abbreviated):
{
"mcp_version": "2025-06-18",
"name": "mcpstandard.dev Reference Server",
"endpoint": "https://mcpstandard.dev/mcp",
"transport": "http",
"auth": { "type": "none" },
"capabilities": ["tools", "resources"],
"categories": ["standards", "reference", "discovery"],
"docs": "https://datatracker.ietf.org/doc/
draft-serra-mcp-discovery-uri/",
"crawl": true
}
8. Security Considerations
8.1. Manifest Spoofing
A malicious actor could expose a fraudulent /.well-known/mcp-server
document. Clients MUST verify that the domain in the manifest
endpoint matches the domain of the original MCP URI.
8.2. DNS Hijacking
DNS TXT records may be spoofed on networks without DNSSEC. Clients
SHOULD prefer the well-known URI mechanism over DNS TXT records.
Operators SHOULD enable DNSSEC where available.
8.3. Rate Limiting
Crawlers may generate excessive requests to /.well-known/mcp-server.
Servers SHOULD implement standard HTTP rate limiting and return
HTTP 429 (Too Many Requests) with Retry-After headers when limits
are exceeded.
8.4. Sensitive Data
The Manifest is a public document. It MUST NOT contain credentials,
tokens, API keys, or any private operational information.
9. IANA Considerations
9.1. URI Scheme Registration
This document requests registration of the "mcp" URI scheme in the
IANA Uniform Resource Identifier (URI) Schemes registry:
Scheme name: mcp
Status: Provisional
Applications: AI agents, MCP clients
Contact: marco.serra@mumble.group
Change controller: IETF
Reference: This document
9.2. Well-Known URI Registration
This document requests registration of the "mcp-server" well-known
URI suffix in the IANA Well-Known URIs registry per [RFC8615]:
URI suffix: mcp-server
Change controller: IETF
Specification document: This document
Related information: None
10. References
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/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[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/rfc/rfc8174>.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[MCP-SPEC] Anthropic, "Model Context Protocol Specification
2025-06-18", 2025,
<https://modelcontextprotocol.io/specification/
2025-06-18>.
10.2. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035,
DOI 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/rfc/rfc1035>.
[RFC7595] Thaler, D., "Guidelines and Registration Procedures for
URI Schemes", RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/rfc/rfc7595>.
[SEP-1649] Soria Parra, D. and N. Cooper, "MCP Server Cards:
HTTP Server Discovery via .well-known", MCP Specification
Enhancement Proposal 1649, October 2025,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/issues/1649>.
[MCPSTANDARD] Serra, M., "mcpstandard.dev -- Reference
Implementation of draft-serra-mcp-discovery-uri",
March 2026, <https://mcpstandard.dev>.
[GH-DISCUSSION] Serra, M., "MCP Server Discovery via mcp:// --
IETF Draft published, looking to coordinate",
GitHub Discussion #2462, March 2026,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/discussions/2462>.
Author's Address
Marco Serra
Mumble Group
Milan, Italy
Email: marco.serra@mumble.group
URI: https://mcpstandard.dev