要約

  • 10月28日付のIETF個人草案は、mDNSとDNS-SDで近くのA2AエージェントやMCPサーバーを見つけ、その後に詳しい記述または接続を得る二段階を示す。
  • 共有リンク上の機器は誰でも候補を告知できる。表示名も記述先もハッシュも告知者が選ぶため、クライアントは接続先を改めて認証する。

名札は本人が書く

研究室や支店では、ツールの置き場所が日々変わる。利用者にホスト名を覚えさせるより、ネットワークにいるサービスを一覧できる方が速い。JakabとBrocknersの改訂草案はそのためにDNS-SDを使う。7月の版からA2Aに加えてMCPを扱い、共通の発見パラメータとリンク外への中継も説明する。提案は個人提出の段階にある。

一覧には出典の弱さがある。草案は、同じ共有リンクの任意のホストがサービスを告知し、TXT欄を自由に埋められると明記する。別のエージェントに似た表示名も付けられる。desc-refは詳しい記述を指すが、運営者を証明しない。新たに加わったdesc-ref-digestは記述が変わったかを知る手掛かりだ。告知自体に認証がない以上、そのハッシュも記述の真正性を保証しない。名札に押された印まで本人の持ち物なのである。

クライアントの仕事は次の段階で重くなる。SRVのホストとポート、経路のヒントから接続先URLを組み立て、A2Aの記述を取るかMCPの接続を始める。そのURLは告知者の影響を受ける。受け入れる方式、アドレス帯、ポート、転送、認証情報、ドメインをまたぐ要求を確認し、通信相手のTLS上の身元を検証する必要がある。httpsを既定値にしても、相手の素性が決まるわけではない。

MCPでは、接続したサーバーがツール、資源、プロンプトを列挙する。近くで見つかったというだけで、その一覧を作業権限に変えてはならない。中継機が告知を別のリンクへ広めても、告知者の身元に新しい裏付けは加わらない。RFC 9665の先着登録は既存の名前を後から奪わせない仕組みだが、最初に登録した運営者が誰かは別の問いだ。

告知は周囲の機器にも見える。A2AやMCPの種別で検索を絞れても、サービスの存在は隠れない。どのインターフェースと区画で告知するか、任意の名前を出すかは運営側の判断になる。見つける機能が答えるのは場所であり、任せる相手かどうかはクライアントが決める。

出典：改訂01、旧版00、IETFの記録、mDNSのRFC 6762、DNS-SDのRFC 6763、サービス登録のRFC 9665。