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, . [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, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [MCP-SPEC] Anthropic, "Model Context Protocol Specification 2025-06-18", 2025, . 10.2. Informative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC7595] Thaler, D., "Guidelines and Registration Procedures for URI Schemes", RFC 7595, DOI 10.17487/RFC7595, June 2015, . [SEP-1649] Soria Parra, D. and N. Cooper, "MCP Server Cards: HTTP Server Discovery via .well-known", MCP Specification Enhancement Proposal 1649, October 2025, . [MCPSTANDARD] Serra, M., "mcpstandard.dev -- Reference Implementation of draft-serra-mcp-discovery-uri", March 2026, . [GH-DISCUSSION] Serra, M., "MCP Server Discovery via mcp:// -- IETF Draft published, looking to coordinate", GitHub Discussion #2462, March 2026, . Author's Address Marco Serra Mumble Group Milan, Italy Email: marco.serra@mumble.group URI: https://mcpstandard.dev