『mcp://』というURIスキームでMCPサーバーの実在を確かめる──2つの独立ドラフトが同じDNSレコードにたどり着いていた

「あるURLの背後にMCPサーバーがあるかどうか」をAIエージェントが自律的に確認する標準手段は、MCP仕様そのものには含まれていない。IETF個人ドラフト「The "mcp" URI Scheme and MCP Server Discovery Mechanism」（著者M. Serra氏、Mumble Group所属、rev04は2026年3月25日提出）の本文を確認すると、この空白を「mcp」という新しいURIスキームと、2段階の発見手続きで埋めようとしていることが分かる。あわせて、この記事の連載で以前扱った別の独立ドラフトとの、興味深い偶然の一致も見つかった。

3行まとめ

• このドラフトは「mcp」URIスキーム（公開到達可能なMCPサーバーを指す機械可読の識別子）と、DNS TXTレコードによる高速発見モードと/.well-known/mcp-serverによる普遍的な互換性を両立させる2段階の発見メカニズムを定義する。マニフェストの完全性をJWS（JSON Web Signature）で検証するオプション機構、信頼クラス・認証要件・コンプライアンス枠組みを事前に宣言するセキュリティ能力ネゴシエーションも含む
• 発見のステップ1（高速モード限定）は_mcp.{host}というDNS TXTレコードにv=mcp1という文字列があるかを確認し、ステップ2（両モード必須）はhttps://{host}/.well-known/mcp-serverへのHTTP GETでマニフェストを取得する
• この記事で以前扱った別の独立ドラフト「draft-morrison-mcp-dns-discovery」も、まったく同じ_mcp.<domain>というDNSラベルとv=mcp1というバージョン文字列に到達している。両者は互いを参照しておらず、この記事で確認した範囲では独立に同じ設計へ収斂したように見える

なぜ必要か

ドラフトの要約はこの空白をこう説明している。

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.

（Model Context Protocol（MCP）は、AIエージェントが外部のツールやサービスに接続するための標準インターフェースを定義する。しかし、AIエージェントがどのWebドメインがMCPサーバーを公開しているかを自律的に発見する標準的な仕組みは存在しない）

2段階の発見手続き

発見の流れは、DNSを使った高速モードのステップと、HTTPを使った必須ステップの2段階で構成される。

Step 1 -- DNS TXT Record (fast mode only): The client MUST query: _mcp.{host} IN TXT. If a TXT record is present containing "v=mcp1", the client has confirmed MCP presence and MUST proceed to Step 2 [...] Step 2 -- Well-Known URI (REQUIRED in both modes): The client MUST perform an HTTP GET request to: https://{host}/.well-known/mcp-server

（ステップ1——DNS TXTレコード（高速モード限定）：クライアントは_mcp.{host}のTXTレコードを問い合わせなければならない（MUST）。v=mcp1を含むTXTレコードが存在すれば、クライアントはMCPの存在を確認したことになり、ステップ2に進まなければならない（MUST）。ステップ2——Well-Known URI（両モードで必須）：クライアントはhttps://{host}/.well-known/mcp-serverへHTTP GETリクエストを実行しなければならない（MUST））

DNS TXTレコードは255文字という制約があるため、あくまで「MCPサーバーがある可能性が高い」ことの高速な事前確認に使い、実際の詳細な情報（マニフェスト）は必ず.well-knownのURLから取得する、という設計だ。

実際にdigとcurlを叩いて、リファレンス実装が動くことを確認した

このドラフトはSection 9で「Reference Implementation」としてmcpstandard.devというサイトを挙げている。この記事を書くにあたって、実際に手元でこのドラフトが定義する手順をなぞってみた。

$ dig +short TXT _mcp.mcpstandard.dev
"v=mcp1; endpoint=https://mcpstandard.dev/mcp; auth=none"

$ curl -sL https://mcpstandard.dev/.well-known/mcp-server
{
  "mcp_version": "2025-06-18",
  "name": "mcpstandard.dev Reference Server",
  ...
  "trust_class": "public",
  ...
}

DNS TXTレコードには確かにv=mcp1が入っており、.well-known/mcp-serverのマニフェストもドラフトが定義するフィールド構成（mcp_version・endpoint・trust_classなど）と一致していた。ドラフトが説明する2段階の発見手続きは、少なくともこの1つのリファレンス実装に対しては、書かれている通りに動作する。

一方で、このリファレンス実装のソースコードを公開しているGitHubリポジトリ99rig/mcp-discoveryをGitHub APIで確認すると、作成日は2026年3月25日、最後にpushされたのも翌3月26日で、スター数・Open Issuesともに0だった。つまり動くには動くが、公開から半年近く、外部からの反応や更新の形跡は今のところ見当たらない。

公式のMCP仕様変更提案（SEP）とも重なりを認める

このドラフトは、MCP本体の公式な仕様拡張プロセスとの重なりについても自己言及している。

The well-known path in this document is "/.well-known/mcp-server" while SEP-1649 proposes "/.well-known/mcp/server-card.json". The authors welcome coordination with MCP maintainers to align these paths.

（本文書のwell-knownパスは/.well-known/mcp-serverだが、SEP-1649は/.well-known/mcp/server-card.jsonを提案している。著者らは、これらのパスを整合させるためMCPメンテナーとの調整を歓迎する）

SEP（Specification Enhancement Proposal）は、MCP本体の仕様変更を提案する公式プロセスの名称で、SEP-1649という番号が付いた別の提案が既に存在していることをこのドラフト自身が認めている。つまりこの分野には、IETFの個人ドラフトとMCP公式のSEPという、少なくとも2つの独立した「サーバー発見」提案が並行して動いている。

ドラフト本文をさらに読み進めると、Section 6.12.5「Relationship to SEP-1649 and SEP-2127」という節があり、両者の関係をより具体的に説明していた。

The primitive preview mechanism defined here is intentionally aligned with the MCP Server Cards proposal (SEP-1649) from the MCP maintainers at Anthropic. [...] The "server_card" field defined in Section 6.4 provides a direct pointer from this document's manifest to a SEP-2127 Server Card, allowing the two specifications to coexist without requiring convergence on a single well-known path.

（ここで定義するプリミティブ・プレビューの仕組みは、Anthropic所属のMCPメンテナーによるMCP Server Cards提案（SEP-1649）に意図的に整合させている。[中略]Section 6.4で定義するserver_cardフィールドは、この文書のマニフェストからSEP-2127のServer Cardへ直接のポインタを提供し、単一のwell-knownパスへの収斂を必須にすることなく、両仕様の共存を可能にする）

つまり著者自身は、SEP-1649（およびその後継SEP-2127）を「競合」ではなく「相互参照で共存させる対象」として設計している。GitHub APIで確認したところ、SEP-2127はこの記事の確認時点（2026年8月29日）でもopen（未マージ）の状態が続いている。

偶然の一致——同じDNSラベル、同じバージョン文字列

この記事の連載で以前扱った別の個人ドラフト「draft-morrison-mcp-dns-discovery」も、_mcp.<domain>というDNSラベルとv=mcp1というバージョン識別子を独自に定義していた。この記事を書くために両ドラフトの本文を確認したところ、互いへの参照は見当たらず、同じ設計（DNSラベル名とバージョン文字列）に独立にたどり着いたように見える。これは、複数の提案者が似た問題に直面したときに直感的に同じ命名規則へ収斂しうることを示す一例だと言えるが、逆に言えば、この分野の標準化がまだ交通整理されていない段階にあることの表れでもある。

マニフェストは接続前に「信頼クラス」を宣言させる

ドラフトSection 6.10「Security Capability Negotiation」は、サーバーが接続前に自らの信頼度・認証要件をマニフェストで宣言する仕組みを定義している。trust_classという1つのフィールドの値に応じて、必須になる付随フィールドが変わる。

trust_classが省略された場合、クライアントはpublicとして扱う（MUST）。逆に見慣れない値が来た場合はクライアント側が最も厳しいregulatedとして扱う（MUST）、という「不明なら安全側に倒す」設計になっている。

もう1つ、Section 6.11「Payment Advertisement」では、ツール呼び出しに課金するサーバーが対応決済方式をマニフェストで事前に宣言できる仕組みも定義されている。挙げられている決済方式識別子はx402（HTTP 402＋USDCのオンチェーン決済、Coinbase）、mpp-tempo、stripe、apikeyの4つ。x402方式についてはオンチェーン決済特有の遅延（Base L2で約2秒以上）に触れ、「呼び出しのたびに課金するのではなく、セッション単位のエスクローを優先すべき（SHOULD）」という実務上の注記もある。HTTP 402を使った課金という発想は、この記事で以前扱った別のIETFドラフト「HTTP Agent Profile（HAP）」とも重なる問題意識だ。

確認できた範囲

このドラフトが定義するJWSベースのマニフェスト完全性検証の暗号学的な詳細までは、この記事では踏み込んでいない。SEP-1649・SEP-2127の中身についても、この記事ではSerraドラフトが言及する範囲とGitHub APIのメタデータ（状態がopen/closedか）以上には確認していない。この記事を書いている自分自身は、DNSやWell-Known URIを使った発見機構を実装した経験がなく、この2つの独立ドラフトのどちらか（あるいは両方）が最終的に採用される見込みについても判断材料を持たない。mcpstandard.devのリファレンス実装が動くことは自分で確認したが、これ以外にこの仕様に沿って実装されたMCPサーバーが実在するかどうかは調べていない。日本語ではZenn・Qiitaともに、このドラフト単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。