Discovery of Model Context Protocol Servers via DNS TXT Records

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

5.1. DNS Location

The Discovery Record is a DNS TXT resource record [RFC1035] published at the label _mcp prepended to the Policy Domain:¶

_mcp.<policy-domain>. IN TXT "<record-value>" ¶

The underscore prefix conforms to the conventions established in [RFC8552] for globally scoped, underscore-prefixed DNS node names.¶

Multiple TXT resource records MAY be published at the same DNS name. When multiple records exist, each MUST independently conform to the syntax defined in this section. Clients MUST evaluate all returned records and select among them using the priority field as described below.¶

5.2. ABNF Grammar

The record value is a semicolon-delimited sequence of key-value pairs. The following ABNF [RFC5234] defines the syntax:¶

``` mcp-record = version *( ";" SP field ) version = "v=mcp1" field = url-field / proto-field / pk-field / epoch-field / cap-field / attest-field / scope-field / priority-field / ttl-field / ext-field / unknown-field¶

url-field = "url=" https-uri proto-field = "proto=" proto-value pk-field = "pk=" algo ":" base64url epoch-field = "epoch=" 1DIGIT cap-field = "cap=" cap-csv attest-field = "attest=" attest-csv scope-field = "scope=" scope-csv priority-field = "priority=" 1DIGIT ttl-field = "ttl=" 1*DIGIT ext-field = "ext=" https-uri unknown-field = token "=" *VCHAR¶

https-uri = "https://" VCHAR algo = "ed25519" base64url = 1( ALPHA / DIGIT / "-" / "" ) proto-value = "streamable-http" / "sse" / "stdio-url" / token cap-csv = cap-token *( "," cap-token ) cap-token = token attest-csv = attest-token *( "," attest-token ) attest-token = token scope-csv = scope-token *( "," scope-token ) scope-token = "tools" / "resources" / "prompts" / "sampling" / "identity" / token token = 1*( ALPHA / DIGIT / "-" / "" ) ```¶

5.3. Field Definitions

5.4. Forward Compatibility

Implementations MUST ignore unknown fields. A parser encountering a field name that it does not recognize MUST skip that field and continue parsing the remaining fields. This rule ensures that future extensions to the record format do not break existing implementations.¶

Breaking changes to the semantics of existing fields require a version bump (e.g., v=mcp2).¶

5.5. Multi-String Concatenation

DNS TXT resource records are limited to 255 bytes per character-string [RFC1035]. When a Discovery Record exceeds 255 bytes, the record MUST be split across multiple character-strings within a single TXT RDATA, which the DNS resolver concatenates per [RFC7208] Section 3.3.¶

Example of a multi-string record:¶

_mcp.example.com. IN TXT ( "v=mcp1; url=https://mcp.example.com; " "pk=ed25519:LongBase64UrlEncodedPublicKeyValueHere; " "epoch=3; attest=employ,contract,alumnus; scope=tools,identity" ) ¶

Parsers MUST concatenate all character-strings within a single TXT RDATA before parsing the semicolon-delimited fields. Parsers MUST NOT treat each character-string as an independent record.¶

6.1. Input

The procedure takes a single input: an Origin Domain. The Origin Domain is typically extracted from an identifier encountered during agent operation -- an email address (user@example.com yields example.com), a URL (https://example.com/path yields example.com), a handle (~user@example.com yields example.com), or a bare domain.¶

6.2. Algorithm

1. Normalize. Convert the Origin Domain to its canonical form: lowercase per [RFC4343], apply IDNA2008 processing where the domain contains non-ASCII labels.¶

2. Construct query name. Prepend the label _mcp. to the normalized Origin Domain, yielding _mcp.<origin>..¶

3. Query DNS. Issue a DNS query for _mcp.<origin>. IN TXT via the client's configured recursive resolver. Clients SHOULD prefer DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) to protect query privacy (see Section 6).¶

4. Handle DNS response.¶

   a. If the response is NOERROR with one or more TXT records, proceed to step 5.¶

   b. If the response is NXDOMAIN or NOERROR with zero TXT records, proceed to step 8 (HTTPS fallback).¶

   c. If the response is SERVFAIL or the query times out, the client MAY retry with exponential backoff or proceed to step 8.¶

5. Parse records. For each TXT RDATA in the response:¶

   a. Concatenate all character-strings within the RDATA.¶

   b. Split the concatenated string on the ";" delimiter, trimming leading and trailing whitespace from each field.¶

   c. Verify that the first field is v=mcp1. If not, discard this record.¶

   d. Extract all recognized fields. Ignore unknown fields per Section 3.7.¶

   e. Verify that the url field is present and contains a syntactically valid HTTPS URL. If not, discard this record.¶

6. Sort by priority. Collect all valid records. Sort by priority in ascending order (lowest value first). Records with equal priority MAY be tried in any order.¶

7. Connect. For each record in priority order:¶

   a. Establish a TLS connection to the host in the url field.¶

   b. If the record contains a pk field, verify the key per Section 3.3.4. On failure, skip to the next record.¶

   c. Initiate the MCP session using the transport declared in proto (defaulting to streamable-http).¶

   d. If the MCP initialize handshake succeeds, discovery is complete.¶

   e. If connection or handshake fails, proceed to the next record. If all records are exhausted, proceed to step 8.¶

8. HTTPS fallback. Attempt HTTPS-based discovery by fetching https://<origin>/.well-known/mcp/server-card.json per SEP-1649 [SEP-1649], or https://<origin>/.well-known/mcp per SEP-1960 [SEP-1960]. If fallback succeeds, proceed with the MCP session. If fallback fails, discovery has failed.¶

6.3. Caching

Clients SHOULD cache the parsed Discovery Record metadata for the duration of the DNS TTL. When the Discovery Record includes a ttl field, clients MAY extend their metadata cache to that duration, but MUST re-validate the underlying DNS record when the DNS TTL expires.¶

Clients that have previously connected to an MCP server and verified its pk SHOULD cache the verified key binding and re-validate it on subsequent connections (Trust On First Use, with periodic re-verification against DNS).¶

7.1. DNS Response Integrity

DNS responses are subject to forgery through cache poisoning, on-path interception, and resolver compromise. A forged Discovery Record could redirect clients to a malicious MCP server.¶

Operators SHOULD sign their zones with DNSSEC [RFC4033] [RFC4034] [RFC4035]. Clients SHOULD request DNSSEC validation from their recursive resolver (the AD flag) and SHOULD treat responses that fail DNSSEC validation as equivalent to NXDOMAIN. When the parent zone is unsigned, DNSSEC provides no protection; clients MUST rely on the TLS and key-pinning mechanisms described below.¶

DNSSEC deployment remains uneven. This specification does not require DNSSEC because doing so would exclude a significant fraction of potential deployers. Instead, DNSSEC is RECOMMENDED as a defense-in-depth layer, with TLS as the primary authentication mechanism.¶

7.2. TLS as Primary Authentication

The url field MUST use the https scheme. The MCP server MUST present a valid TLS certificate for the hostname in the URL, issued by a certificate authority trusted by the client.¶

TLS authenticates the server to the client and provides confidentiality and integrity for the MCP session. Even if the DNS record is forged, an attacker cannot present a valid TLS certificate for the legitimate server's hostname without compromising the WebPKI trust chain.¶

7.3. Key Pinning via the pk Field

The optional pk field provides an additional layer of authentication independent of the WebPKI. When present, the client verifies that the server's Ed25519 key matches the key declared in DNS.¶

This binding is valuable in two scenarios:¶

1. Certificate authority compromise. If a CA issues a fraudulent certificate for the server's hostname, the pk binding detects the discrepancy because the attacker does not possess the correct Ed25519 private key.¶

2. Attestation verification. Signed artifacts (attestations, identity claims, x402 payment receipts) issued by the server can be verified against the pk in DNS, providing a verification path that does not depend on the TLS session.¶

Key pinning introduces a risk of key loss. If the operator loses the private key corresponding to the published pk, legitimate clients will reject the server. Operators MUST maintain secure key backups and SHOULD implement the key rotation procedure described below.¶

7.4. Key Rotation

Key rotation follows the overlapping-key pattern established by DKIM:¶

1. Generate a new Ed25519 keypair.¶

2. Update the MCP server to accept both the old and new keys.¶

3. Publish a new Discovery Record with the updated pk and incremented epoch.¶

4. Wait for at least 2x the DNS TTL to allow cached records to expire.¶

5. Remove the old key from the MCP server.¶

During the overlap window (steps 2-4), clients with cached old records and clients with fresh new records both succeed. The epoch field enables verifiers to detect stale claims: a claim signed with epoch=N is revoked once the Discovery Record shows epoch=N+1, unless the claim's expiry predates the rotation event.¶

Operators SHOULD NOT rotate keys more frequently than once per DNS TTL period. Frequent rotation increases the risk of verification failures during the overlap window.¶

7.5. Replay and Freshness

Discovery Records are public and cacheable. An attacker who observes a Discovery Record can replay it, but this provides no advantage: the record contains no secrets, and replaying a legitimate record simply directs clients to the legitimate server.¶

The epoch field provides freshness for signed artifacts. A verifier that encounters a claim with an epoch lower than the current Discovery Record epoch knows the signing key has been rotated and can apply epoch-based revocation.¶

MCP servers that issue signed attestations SHOULD include a nonce and timestamp in each attestation. Verifiers SHOULD reject attestations older than a policy-defined maximum age (e.g., 300 seconds for session-bound attestations).¶

7.6. Denial of Service

An attacker who can inject DNS responses (absent DNSSEC) could publish a Discovery Record pointing to an attacker-controlled server, or could inject NXDOMAIN to suppress discovery. The TLS requirement mitigates server impersonation (the attacker cannot obtain a valid certificate), but suppression of discovery cannot be mitigated at the DNS layer alone.¶

Clients SHOULD implement the HTTPS fallback described in Section 4 to reduce the impact of DNS-layer suppression.¶

7.7. Zone Control and Record Authenticity

The _mcp. label is under the Policy Domain's own DNS zone. Publication of the Discovery Record is therefore an authenticated act: only an entity with write access to the zone can create or modify the record. This matches the trust model of DKIM, MTA-STS, and DMARC, where the zone holder's control of the DNS record is the root of authority.¶

Delegated subdomains (e.g., _mcp.dept.example.com) inherit the trust properties of the subdomain's zone. If dept.example.com is delegated to a separate zone with its own set of nameservers, the operator of that zone controls its Discovery Record independently. Clients MUST NOT assume that a Discovery Record at a subdomain is authorized by the parent domain's zone operator.¶

7.8. Attestation Scope as Security Boundary

The attest field provides a structural defense against capability creep. By publishing the set of attestation types it will issue, a domain establishes an upper bound that verifiers can enforce. An MCP server that publishes attest=employ,contract cannot legitimately issue a director attestation, and verifiers MUST reject such claims even if the cryptographic signature is valid.¶

This mechanism transforms the DNS record into a capability declaration: the domain operator explicitly consents to a bounded set of claim types, and verifiers enforce that boundary. The operator can expand or contract the attest set at any time by updating the DNS record; the change takes effect at DNS TTL expiry.¶

7.9. Multi-Server Key Consistency

When multiple Discovery Records are published at the same DNS name (for failover), the records MAY declare different pk values (one per server) or the same pk value (shared key). Operators using distinct keys per server MUST ensure that all servers share the same epoch. A split-epoch configuration (where different servers advertise different epoch values) creates ambiguous revocation semantics and MUST be avoided.¶

8.1. DNS Query Metadata

DNS queries are visible to the recursive resolver, and potentially to on-path observers between the client and the resolver. A client resolving _mcp.example.com reveals to its resolver that it intends to interact with example.com via MCP.¶

Clients concerned with query metadata leakage SHOULD use DNS-over-HTTPS (DoH) [RFC8484] or DNS-over-TLS (DoT) [RFC7858] and SHOULD prefer resolvers that publish strong privacy policies (e.g., no query logging, GDPR compliance).¶

8.2. Discovery Record Content

The Discovery Record itself is public by design. It contains no per-user information. The fields describe the MCP server's endpoint, transport, and capabilities -- all of which are properties of the domain operator, not of any individual user.¶

Operators who wish to keep the existence of their MCP server private SHOULD NOT publish a Discovery Record and SHOULD rely on out-of-band configuration or authenticated HTTPS-based discovery.¶

8.3. Individual Privacy

The Discovery Record is a domain-level record. This specification does not define per-user DNS records and explicitly discourages them. Individual identity resolution, where applicable, occurs at the MCP application layer behind the server endpoint, subject to application-level consent and access control mechanisms that are outside the scope of this document.¶

A domain that publishes a Discovery Record does not reveal anything about the individuals associated with that domain. The server behind the endpoint determines what information, if any, is disclosed about individuals, and under what conditions.¶

8.4. Caching and Linkability

Clients that cache Discovery Record metadata (including pk bindings) should be aware that cached state can be used for cross-session linkability if the cache is not partitioned by context. Implementations SHOULD partition Discovery Record caches by the requesting context (e.g., per-conversation or per-user) to prevent cross-context tracking.¶

9.1. Underscored DNS Node Name Registration

This document requests IANA to register the following entry in the "Underscored and Globally Scoped DNS Node Names" registry established by [RFC8552]:¶

+--------+------------+-----------------------------+ | RR Type| _NODE NAME | Reference | +--------+------------+-----------------------------+ | TXT | _mcp | [this document], Section 3 | +--------+------------+-----------------------------+ ¶

The _mcp label is used to publish Discovery Records for Model Context Protocol servers as defined in Section 3 of this document.¶

9.2. No New RR Type

This document does not request registration of a new DNS resource record type. The Discovery Record uses the existing TXT RR type. The historical experience of SPF [RFC7208], which registered a dedicated RR type 99 that was subsequently deprecated due to lack of deployment, strongly argues against proposing a new RR type for MCP discovery. TXT records are universally supported by DNS operators, resolvers, management interfaces, and CDN-fronted services.¶

9.3. Version Registry

This document defines the version tag v=mcp1. Future versions of the Discovery Record format (e.g., v=mcp2) SHOULD be coordinated with the Agentic AI Foundation's MCP specification process [MCP]. This document recommends that the Agentic AI Foundation establish a version registry for the v=mcpN tag, with IETF liaison for cross-registry coordination if an IETF working group is chartered for MCP discovery.¶

10.1. Minimal Record

The simplest valid Discovery Record contains only the version and endpoint URL:¶

_mcp.example.com. IN TXT "v=mcp1; url=https://mcp.example.com" ¶

A client discovering this record connects to https://mcp.example.com using the default streamable-http transport with no authentication requirement and no key pinning. This is appropriate for public MCP servers offering openly available tools.¶

10.2. Identity-Bound Record

A server that issues signed attestations and participates in identity resolution publishes a full record with key pinning, epoch tracking, and attestation scope:¶

_mcp.truealter.com. IN TXT ( "v=mcp1; url=https://mcp.truealter.com; " "proto=streamable-http; " "pk=ed25519:dGhpcyBpcyBhIHNhbXBsZSBrZXk; " "epoch=3; cap=E4; " "attest=employ,contract,alumnus,member; " "scope=tools,resources,prompts,identity; " "ext=https://truealter.com/.well-known/alter-ext.json" ) ¶

Clients connecting to this server:¶

1. Verify the Ed25519 key against the TLS session or HTTP Message Signatures.¶

2. Know that signed claims carry kid=ed25519:dGhpc...#3 and can be revoked by incrementing the epoch.¶

3. Can fetch the extension document for protocol-specific metadata (e.g., identity resolution, payment addresses).¶

4. Know the server supports identity resolution (scope=...identity) and that it is authorized to issue employment, contract, alumnus, and membership attestations.¶

10.3. Multi-Server Failover

An operator running geographically redundant MCP servers publishes multiple records with distinct priorities:¶

_mcp.bigcorp.com. IN TXT "v=mcp1; url=https://mcp-us.bigcorp.com; priority=10; pk=ed25519:USKeyHere; epoch=5" _mcp.bigcorp.com. IN TXT "v=mcp1; url=https://mcp-eu.bigcorp.com; priority=20; pk=ed25519:EUKeyHere; epoch=5" _mcp.bigcorp.com. IN TXT "v=mcp1; url=https://mcp-ap.bigcorp.com; priority=30; pk=ed25519:APKeyHere; epoch=5" ¶

Clients sort by priority and attempt the US endpoint first, failing over to EU, then AP. All three servers share the same epoch, ensuring consistent revocation semantics. The pk values MAY differ across servers (each server holds its own keypair) or MAY be identical (shared key, centralized signing).¶

10.4. Handle-Scoped Record

A subdomain-scoped record enables sovereign individuals who operate their own domain to publish a personal MCP endpoint:¶

_mcp.blake.alter.dev. IN TXT "v=mcp1; url=https://alter.dev/~blake/mcp; scope=identity; pk=ed25519:PersonalKeyHere; epoch=1" ¶

This record declares that identity queries for blake within the alter.dev domain should be directed to https://alter.dev/~blake/mcp. Handle-scoped records are optional and are intended for the specific use case of individuals who operate their own identity endpoint. The common case -- where individuals are resolved through an organizational MCP server -- requires only a single record at the organizational domain.¶

11.1. Relationship to HTTPS RR (RFC 9460)

The SVCB/HTTPS DNS record type [RFC9460] provides service binding with extensible key-value parameters, and could in principle carry MCP discovery metadata. However, as of 2026, HTTPS RR deployment is uneven, DNS management interfaces expose it inconsistently, and no MCP-specific SvcParamKey has been registered.¶

This specification uses TXT records for Phase 1 deployment. A future revision MAY define an MCP-specific SvcParamKey for HTTPS RR, enabling operators to publish MCP metadata alongside HTTPS service parameters. Such a revision would be appropriate once HTTPS RR resolver and management tooling reaches the deployment level currently enjoyed by TXT records.¶

11.2. Relationship to DID Methods

The W3C Decentralized Identifier (DID) ecosystem includes methods that resolve via DNS. did:web resolves to https://<domain>/.well-known/did.json. did:dns is in early development.¶

The Discovery Record is not a DID method and does not produce DID Documents. However, the pk field in a Discovery Record can serve as a verification method reference in a DID Document, and a did:web document can reference the MCP endpoint declared in the Discovery Record. The two mechanisms are complementary: DID provides a general-purpose identifier framework; the Discovery Record provides MCP-specific endpoint discovery.¶

11.3. Relationship to .well-known/mcp

The .well-known/mcp endpoint proposed in SEP-1960 [SEP-1960] and the Server Card proposed in SEP-1649 [SEP-1649] are the HTTPS-based discovery mechanisms for MCP. This specification defines the DNS-based discovery layer and explicitly designates the .well-known/mcp endpoint as the fallback when DNS discovery fails or returns no result.¶

The intended deployment is layered: DNS provides the fast, cacheable bootstrap; the Server Card provides the full metadata. Operators SHOULD publish both a Discovery Record and a Server Card. Clients SHOULD attempt DNS discovery first and fall back to HTTPS discovery.¶

11.4. Relationship to Agent Identity and Discovery (AID)

The Agent Identity and Discovery protocol [AID] uses _agent.<domain> TXT records with a v=aid1 version tag to provide cross-protocol meta-discovery (MCP, A2A, OpenAPI, and others). The _mcp. record defined in this document is MCP-specific and provides richer MCP-native fields (epoch, attest, scope, proto).¶

The two mechanisms are complementary. _agent.<domain> is the cross-protocol meta layer; _mcp.<domain> is the MCP-specific refinement. A domain MAY publish both records. A client that discovers MCP support via _agent.<domain> MAY subsequently query _mcp.<domain> for detailed MCP metadata.¶

11.5. Relationship to Google Agent-to-Agent Protocol (A2A)

The Google Agent-to-Agent Protocol (A2A) uses /.well-known/agent-card.json for HTTPS-based agent discovery. A2A does not currently define a DNS-based discovery mechanism.¶

The _mcp. Discovery Record is MCP-specific and does not apply to A2A endpoints. However, the _mcp. pattern is structurally generalizable: a future _a2a.<domain> TXT record could follow the same conventions (version prefix, URL field, key pinning, priority) to provide DNS-based discovery for A2A servers. This document does not define such a record but notes the pattern's applicability.¶

11.6. Coexistence with SEP-1959

MCP SEP-1959 [SEP-1959] proposes DNS-based MCP server identity verification using a TXT record format with fields including auth, transport, and sec. This document defines a complementary but more general mechanism. The key differences are:¶

• This document defines epoch for key-lifecycle management, which SEP-1959 does not address.¶

• This document defines attest for attestation scope bounding, which SEP-1959 does not address.¶

• This document defines a formal ABNF grammar and explicit forward-compatibility rules.¶

The authors intend to coordinate with the SEP-1959 author to merge or align the two proposals. Where the field semantics overlap (version, URL, transport, key), convergence on a single field vocabulary is desirable.¶

13.1. Normative References

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

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

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[RFC7208]

Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.

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

[RFC8461]

Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/info/rfc9421>.

[MCP]

Agentic AI Foundation, "Model Context Protocol Specification", 2026, <https://modelcontextprotocol.io>.

13.2. Informative References

[RFC6376]

Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.

[RFC7489]

Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/info/rfc9460>.

[SEP-1649]

"MCP Server Cards", n.d., <https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649>.

[SEP-1959]

"DNS-Based MCP Server Identity Verification", n.d., <https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1959>.

[SEP-1960]

".well-known/mcp Discovery Endpoint", n.d., <https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1960>.

[SEP-2127]

"MCP Server Cards (PR)", n.d., <https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127>.

[AID]

"Agent Identity & Discovery", n.d., <https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-identity-discovery/>.

[SERRA]

"MCP Discovery URI", n.d., <https://datatracker.ietf.org/doc/draft-serra-mcp-discovery-uri/02/>.