MCP Roots は「tool 接続規格」ではなく permission 境界の primitive
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- MCP Roots は、AI agent に『このフォルダだけ見てよい』と伝えるための標準的な境界表現だ。
- 重要なのは tool 接続そのものではなく、server が見てよい workspace 範囲を protocol の中で共有できる点にある。
- そのため client は見せる作業領域を先に出し、server はその外を前提にしない設計を取りやすくなる。
- 技術的には client が `roots` capability を宣言し、server が `roots/list` で一覧を取得し、必要なら `notifications/roots/list_changed` で変更通知を受ける。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
MCP を『tool を呼べる共通接続規格』とだけ捉えると、関心は schema や transport に寄りがちです。Roots spec はそこへ別の軸を足します。client は filesystem roots を expose し、server は `roots/list` で一覧を取得し、client が対応していれば `listChanged` で変化通知まで受けられます。つまり MCP は、tool を増やす規格であると同時に、見せる作業領域を制御する規格でもあります。
なぜ重要か
日本の社内導入では、agent が『どこまで見えるのか』が承認の最初の停止点になりやすいです。MCP の説明が tool use だけだと、その問いに答えられません。Roots を理解していれば、『server が万能に見える設計』ではなく『client が選んだ roots の範囲内で動く設計』へ話を進められます。開発者にとっても、multi-repo workspace、途中での root 追加、server ごとの閲覧範囲差分、list 変更時の再同期を protocol 上の概念として整理できます。
技術的ポイント
- Roots は filesystem roots を server に公開する標準方式で、server がどの directories/files にアクセスできるかの境界を伝える。
- root 対応 client は initialization 時に `roots` capability を宣言し、`listChanged` が true なら root 変更通知も送る。
- server は `roots/list` request で root 一覧を取得し、結果は `file://` URI と任意の表示名 `name` を含む。
- root 変更時は `notifications/roots/list_changed` を送る。server 側には『workspace が変わったら再評価する』責務が発生する。
- spec は roots 未対応 client に対して JSON-RPC error `-32601` を返す例も示している。対応有無を capability で確認する実装が必要。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| roots | ルーツ / 作業領域境界 | MCP server に見せる filesystem の起点。tool 接続より前に permission 範囲を決める primitive。 |
| filesystem boundary | ファイルシステム境界 | どこまで読めるか、触れるかの範囲。agent や MCP server の permission 設計で最初に決める境界。 |
| workspace picker | ワークスペース選択UI | どの repo やフォルダを root にするか選ぶ UI。Roots と結びつく実装上の入口。 |
| trust boundary | 信頼境界 | どこから先を未信頼入力として扱うかの境目。ローカル設定や起動時フックも trust 前なら未信頼として扱う。 |
| MCP | Model Context Protocol | AI アプリが外部ツールやデータ源に接続するためのプロトコル。ツールだけでなく resources / prompts も含む。 |
試すなら
- 自分の MCP client / host で、server に repo 全体を見せている箇所がないか確認し、root 単位で絞れる設計へ寄せる。
- workspace picker や project selector があるなら、その UI 操作を `roots/list` と `list_changed` にどう対応づけるか決める。
- multi-repo 利用時は root を複数返す設計にし、server 側で『見えていない repo を前提にしない』検証を入れる。
- root 変更後に server cache や index をどう再同期するか、通知受信からの再読込手順を確認する。
注意点
- Roots は permission boundary を表すが、それだけで OS 権限や sandbox が成立するわけではない。実ファイルアクセス制御は別層で必要。
- spec は `file://` URI 前提で、クラウド storage や仮想 workspace を直接一般化しているわけではない。拡張時は解釈を慎重にすべき。
- listChanged 対応を入れても、server 側が古い root 前提の cache を保持したままだと境界逸脱が起こりうる。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。