MCPまわりを数日続けて見ていると、便利そうな小道具の名前がすぐ増えます。registryを確認するもの、stdioの終了を確認するもの、URL elicitationの確認画面を再現するもの、runtime faultを分類するもの。どれも必要に見えますが、最初から別々のツールとして作ると、利用者が本当に知りたい問いから少し離れます。
自分の週次整理では、最初の問いを「このMCP serverは良いか」ではなく、「今回のtask scopeで、このtool callを許してよいか」に寄せることにしました。つまり、MCP導入前チェックは、個別の検査名を増やす前に mcp-scope-preflight の1枚のreportへ畳むほうが扱いやすい、という判断です。
利用者が困るのは、server一覧ではなく今回の許可範囲
MCP RegistryやInspectorは、serverを見つけたり、tool一覧を確認したり、実際にdebugしたりする入口として重要です。公開されている MCP Inspector や Inspector docs を見ても、MCP server開発と検証のための足場はかなり整っています。
ただ、coding agentにMCPを渡す場面で利用者が迷うのは、もう少し手前です。今回の作業はreadだけで済むのか。write-capableなtoolを渡す理由はあるのか。browser profileや外部endpoint、telemetry、update check、secret envをどこまで見ているのか。tool listが見えることと、そのtoolを今回呼んでよいことは別です。
小道具を増やす前に、入力を3つに絞る
最初のpreflightは、実MCP serverを起動しなくても成立します。入力は次の3つだけで十分です。
task-scope.md: 今回の作業で許される操作、触ってよい対象、触らない対象。tools.json: MCP serverやconnectorが公開しているtoolの低詳細な一覧。planned-calls.json: agentが実行しようとしているtool callの予定。
ここから allowed、needs_review、blocked の3段階だけを返す。最初はこのくらい粗くてよいと思っています。目的は自動で許可することではなく、人間や次のagentが「どこで迷ったのか」を短く読める状態にすることです。
registry、stdio、elicitation、faultは別名で始めない
2026年6月の週次整理では、MCP関連の候補がいくつも並びました。mcp-registry-preflight、mcp-stdio-lifecycle-check、mcp-elicitation-replay-fixtures、mcp-fault-fixture-kit。それぞれ単独でも面白いのですが、初期段階で全部を別repoや別CLIにすると、判断の出口が散らばります。
そこで、最初はscope preflightの中に「将来のsubcheck」として置くくらいがちょうどよさそうです。registryはmetadataの未確認項目、stdioはlifecycleの未確認項目、elicitationはuser confirmationの未確認項目、faultは実行後に分かったphase別の失敗候補として扱う。名前を増やすより、1枚のreportに同じ語彙で並べます。
初期reportに入れる項目
最小の scope-report.md には、次の項目だけを入れればよいと考えています。
- decision:
allowed、needs_review、blockedのどれか。 - reason: なぜその判断になったかを1から3行で書く。
- operation class: read、write、execute、navigate、upload、deleteなどの分類。
- scope mismatch: task scopeに含まれない対象や操作があるか。
- unknowns: telemetry、external endpoint、browser profile、secret env、version freshnessなど未確認の点。
このreportには、credential、token、cookie、private URL、実host名、raw logを入れません。実設定を丸ごと読ませるのではなく、syntheticなtool listや低詳細のplanned callだけを扱う。公開可能なfixtureとして残せる粒度にしておくと、後でテストデータや記事にも使いやすくなります。
「許可しない成功」も出力に含める
coding agentの運用では、何かを実行した結果だけが成果ではありません。scope外のtool callを止めた、write権限が必要な理由を説明できなかった、人間確認へ回した。このような「許可しない成功」も、reportの成果として残すべきです。
たとえば、issueを読むだけのtaskでPR merge系toolがplanned callに入っていたら blocked。GitHubのreadだけで足りるが、remote-only toolの前提が未確認なら needs_review。task scope、tool list、planned callが揃っていてread-onlyなら allowed。この程度の単純な分類でも、agentが勝手に進んだように見える事故は減らせます。
今日の結論
MCPの導入前チェックは、最初からregistry、stdio、elicitation、faultを別々の道具にしなくてもよさそうです。まずは task-scope.md + tools.json + planned-calls.json から、今回の作業で呼んでよいtool callかどうかを1枚のreportに落とす。そこで未確認になった項目を、将来のsubcheckとして育てるほうが安全です。
新しいMCP serverを足す時に大事なのは、便利なtoolをどれだけ増やすかではなく、今回の作業に必要な権限だけを渡せているかです。scope preflightは派手な機能ではありませんが、coding agentに外部toolを渡す前の、いちばん実務的な確認層になりそうです。
