MCP server がユーザーに追加情報を求める場面は、これまで「client がフォームを出す」ものとして捉えがちでした。しかし、MCP の draft elicitation 仕様では、form mode と URL mode が明確に分かれています。特に URL mode は、API key、access token、payment credentials などを MCP client や LLM context に通さないための逃がし道として重要です。
この記事は、2026年6月4日の調査メモをもとに、CLI/TUI の MCP client が URL mode elicitation を扱う時に、確認画面へ最低限出したい情報を整理したものです。根拠は MCP draft elicitation specification、SEP-1036、2026 MCP Roadmap です。
formで聞いてよい情報と、URLへ逃がす情報を分ける
draft 仕様では、form mode は構造化された非機密入力を client 経由で集めるためのものです。一方で、password、API key、access token、payment credentials のような機密情報は form mode で扱わず、URL mode を使う前提になっています。
この分離は、MCP client の実装者にとってかなり大きな意味があります。フォームをきれいに表示するだけでは足りません。入力欄の名前や description に「token」「api key」「password」「secret」などが見えた時、その request 自体を危険信号として扱えるかが、client 側の品質になります。
URL modeは「MCP serverへのログイン」ではない
混乱しやすい点は、URL mode が MCP client から MCP server へ接続するための認可ではないことです。MCP server がさらに第三者サービスへ接続する必要がある時、ユーザーを外部URLへ案内し、MCP protocol の外で認可や機密入力を完了させるための仕組みです。
つまり、client は「このURLを開けば全部安全」と保証する役ではありません。client が担うのは、どの server が、何のために、どの host へ移動させようとしているかをユーザーに見せ、accept / decline / cancel を明確に選べるようにすることです。
CLI/TUIで最低限見せたい5項目
- 要求元の server 名: どの MCP server が要求しているか。tool 名だけではなく、接続先として認識している server 単位で出す。
- 要求理由: elicitation の message をそのまま流すだけでなく、長すぎる場合も省略しすぎない。ユーザーが判断できる粒度を保つ。
- 遷移先の host: URL 全体より先に domain / host を目立たせる。特にCLIでは、長いURLの中に埋もれやすい。
- 送られるものと送られないもの: URL mode では、機密値そのものは MCP client に返らないことを説明しつつ、URLを開く操作自体には同意が必要だと示す。
- decline / cancel / retry: accept だけを強く見せない。通知が来ない場合に手動で戻れる操作も残す。
特に CLI/TUI は画面が狭く、browser のようなアドレスバーも常に見えるわけではありません。だからこそ、host、server 名、理由、状態を短い確認パネルとして固定表示する価値があります。
acceptは完了ではない
URL mode でユーザーが accept しても、それは「URLを開くことに同意した」だけです。外部ページでの入力やOAuthフローが完了したとは限りません。仕様上も、server は out-of-band interaction の完了後に completion notification を送れる形になっています。
ここを雑に扱うと、CLI側では「承認したのに進まない」「どこまで終わったのか分からない」という体験になります。実装では、少なくとも次の状態を分けておきたいです。
- ユーザーがURL遷移に同意した
- 外部ページでの処理待ち
- completion notification を受け取った
- 通知が来ないため、手動retryまたはcancel待ち
小さなチェックツールにできる部分
今回の調査で、`mcp-elicitation-lint` のような小さなツール候補も見えました。MCP server や tool 定義、prompt description、test fixture を読み、次のような点を静的に警告するものです。
- form mode の schema に password / token / api_key / secret / payment らしき property がないか
- URL mode request に elicitationId があるか
- 確認UIに server 名、message、target host を出しているか
- completion notification を unknown ID と completed ID で無視できるか
- accept / decline / cancel の3状態をテストしているか
これは大きな framework である必要はありません。まずは JSON fixture と Markdown report を出すだけでも、agent runtime や connector を増やす前の preflight として効きます。
まとめ
MCP は 2026 roadmap でも transport、agent communication、governance、enterprise readiness が重点領域になっており、実験的な便利機能から運用品質へ関心が移っています。URL mode elicitation も、その流れの中で見ると「フォーム入力の追加機能」ではなく、機密情報を client と LLM context から遠ざけるための安全境界です。
CLI/TUI の MCP client を作るなら、URLを開けるだけで終わりにせず、要求元、理由、host、状態、拒否導線をきちんと見せる。そこまでを最小の実装単位にすると、MCP connector を増やす時の不安がかなり減ります。
