MCP Resources は「全部 tool にする雑設計」をやめるための基礎仕様

要点

要点まとめ

MCP Resources は、AI agent に読ませる資料と、実際に実行させる操作を分けるための仕様である。
要は「文書を読む入口」と「何かを実行する入口」を別にし、参照情報まで全部 tool に詰め込まないようにする面だ。
そのための仕組みとして、一覧を見る、本文を読む、条件付きで資料を組み立てる、更新を知らせる、といった面が protocol に定義されている。
日本で起きやすい『FAQ も schema も全部 tool』にする雑設計を、権限、UI、キャッシュ、監査の観点から引き上げる基礎仕様として読める。

読解

何が変わったのか

この仕様は、MCP を tool execution の規格としてだけ理解していた読み方を崩します。server は `resources` capability を宣言し、client は `resources/list` で使える resource を発見し、`resources/read` で中身を読む。さらに `resources/templates/list` では条件で組み立てる資料の型も公開でき、`listChanged` や `resources/subscribe` により変化通知も扱えます。つまり MCP は command catalog だけでなく、context catalog とその更新面まで含む規格だと分かります。

日本の文脈

なぜ重要か

日本の開発現場では、function calling 的な理解の延長で『見せたい情報も全部 tool にしてしまう』設計が起きやすいです。しかしその形だと、read-only 情報にまで実行権限や副作用の匂いが付き、UI での選択、キャッシュ、監査ログ、優先度付けがやりにくい。Resources を理解すると、『agent に何を読ませ、何を実行させるか』を protocol レベルで分けて考えられます。PM や導入担当にとっても、tool 数ではなく context surface を説明できる点が大きいです。

技術ポイント

技術的ポイント

`resources` capability は server が resource 面を持つことを示し、`subscribe` と `listChanged` は任意機能だ。つまり更新追跡なしの静的 resource server も作れる。
`resources/list` は resource の URI、name、任意の title、description、mimeType、size などを返す。resource は URI で一意に識別される。
`resources/read` は text だけでなく binary content も返せる。したがって schema や markdown だけでなく画像やバイナリ資産も対象になりうる。
resource templates は、URI template を使って条件付きで資料を取り出す仕組みで、固定ファイル列挙だけが resource ではない。
annotations は resource に付ける補助メタデータで、`audience`、`priority`、`lastModified` などを使って client が見せ方を判断できる。

用語

英日キーワード

英語	日本語	補足
resources	リソース / 参照コンテキスト	モデル理解の材料になる共有データ。tool と分けて扱うことで read-only 文脈と action を分離できる。
resources/list	リソース一覧取得	利用可能 resource を発見する request。client がどの参照面を見せるかを制御する入口になる。
resources/read	リソース読取	指定 URI の内容を取得する request。text だけでなく binary content も対象になりうる。
resource templates	リソーステンプレート	パラメータ付き resource を公開する仕組み。固定ファイル列挙ではない context surface を表現できる。
read-only context	読み取り専用コンテキスト	action ではなく参照目的の情報面。resources を全部 tool に押し込めないための整理軸。
MCP	Model Context Protocol	AI アプリが外部ツールやデータ源に接続するためのプロトコル。ツールだけでなく resources / prompts も含む。

試す

試すなら

自分の MCP server で返している tool 一覧を見て、『実行』ではなく『参照』だけのものを分離候補として洗い出す。
FAQ、schema、policy、repo docs のような read-heavy 情報は resource 化し、更新頻度が高いなら `listChanged` や subscription が必要か考える。
URI 命名を先に決める。`file://`、`git://`、独自 scheme のどれを使うかで、client 表示や cache 設計が変わる。
resource を増やす時は、tool と違って『自動で model に入れるか』『ユーザーに選ばせるか』という UI 判断も同時に設計する。

注意

注意点

Resources は read-only 文脈に向くが、仕様自体が OS 権限や sandbox を保証するわけではない。実アクセス制御は別層で必要。
公開日は spec version 2025-06-18 を採用しているが、個別ページに別の公開日表示は見当たらなかった。
どの resource を自動投入するかは protocol では決まらない。client 実装次第なので、resource を定義しただけで適切に使われるとは限らない。