ListMcpResourcesTool（リストエムシーピーリソーシズツール）

Claude Code に MCP サーバーを1つ以上つないでいて、@ で参照できる読み取り専用データの一覧を確認したい人向け

ListMcpResourcesTool は、Claude Code に外付けでつないだ MCP サーバーが「読み取り専用の資料」として公開しているデータの一覧を取りに行く内部ツールです。普段のチャットで @ をタイプして候補が出てくる、あの裏側で動いてる仕組み。読者が直接「ListMcpResourcesTool を叩いて」と指示することはほぼなく、Claude が自動で呼んでくれる位置づけです。

ただし、これは つないだ MCP サーバー側が resources 機能を実装していないと、ツール自体は存在しても返ってくるのは空っぽになります。ここが最初の落とし穴。

噛み砕くと

MCP サーバーは「新しい職場に持ち込んだ外部キャビネット」みたいなものです。中には3種類の引き出しがあって、tools は実行ボタン、prompts は定型あいさつ文、resources は参照資料、と用途が分かれています。

ListMcpResourcesTool は、その中の「resources の引き出し」だけを開けて、入ってる資料のラベル一覧を読み上げてくれる係。資料そのものを取り出すのは別の係、ReadMcpResourceTool の仕事です。引き出し自体が空のキャビネット、つまり resources を実装してない MCP サーバーに係を行かせても、何も持って帰ってきません。

大事な前提：MCP サーバー側が resources を提供してないと、出てくるのは空っぽ

ListMcpResourcesTool は Claude Code に最初から組み込まれている内部ツールで、ユーザー側のセットアップは要りません。ただし「resources を公開している MCP サーバー」を claude mcp add で1つ以上つないでいないと、呼んでも空っぽの一覧が返るだけ。

MCP サーバーは作者の好みで、tools だけ実装するもの、resources だけ実装するもの、3種類全部実装するものがあります。GitHub の MCP サーバーは issue や file を resources として出してくれるタイプ。Slack 系は tools 寄りで resources を出さないものが多い、といった違いがあります。

「GitHub MCP サーバーを繋いで、見える資料の一覧を確認する」流れを実演

具体例として、GitHub の MCP サーバーをつなぎ、そこから見える issue や file を @ で引用するまでの流れを追います。

ステップ1: GitHub MCP サーバーを登録する

ターミナルで Claude Code のサブコマンドを叩いて MCP サーバーを追加します。公式 MCP docs の「Example: Connect to GitHub for code reviews」で案内されているのは、HTTP transport 経由で GitHub の MCP エンドポイントに繋ぐ形です。

$ claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

YOUR_GITHUB_PAT の部分は GitHub の個人アクセストークンに差し替えます。GitHub のトークン設定画面で、アクセスしたいプロジェクトへの読み取り権限つきのトークンを発行して貼り付けます。

これで「github」という名前で MCP サーバーがこのプロジェクトに紐づきました。

ステップ2: Claude Code セッションを開く

同じフォルダで通常通り起動します。

$ claude

起動時に Claude Code は登録済みの MCP サーバーと握手をして、「お前は何を提供できるんだ？」と聞きにいきます。GitHub MCP サーバーは「tools いくつかと、resources いくつか出せます」と答える。この時点で ListMcpResourcesTool が裏で1回叩かれて、Claude のメモリに resource 一覧が読み込まれます。

ステップ3: チャット欄で @ をタイプする

普通にプロンプトを打つ流れの中で、半角の @ マークを1個タイプすると、入力補完メニューがニュッと出てきます。

> @
   📁 README.md
   📁 src/
   🔗 github:issue://1
   🔗 github:issue://2
   🔗 github:file://README.md@main

ローカルのファイル候補と、MCP 経由の resource 候補が同じメニューに混ざって出てくるのがポイント。github: から始まっている行が、ListMcpResourcesTool が引っ張ってきた「GitHub 側で参照可能な資料」のリストです。

ステップ4: 特定の issue を引用してみる

例えば issue 番号 123 番について Claude に相談したいとき、こう書きます。

> @github:issue://123 の内容を読んで、原因を推測してください

@server:protocol://resource/path という形式で、「どのサーバーの、どの種類の、どの場所か」を一行で指定する書き方。これを送信すると、Claude が裏で ReadMcpResourceTool を呼んで issue#123 の本文・コメント・ラベルを取りに行きます。資料は自動で添付された扱いになって、Claude の返答に組み込まれます。

ここで初心者がやりがちな勘違いを1つ。@github:issue://123 はリンクの貼り付けではなく「中身を読んで会話に含めろ」という指示です。Claude は単にリンクを眺めるんじゃなく、本当に内容を fetch している。

ステップ5: 複数の resource を組み合わせる

resource は一度のプロンプトで複数指定できます。

> @github:issue://123 と @github:file://src/auth.ts を見比べて、
> issue で報告されている認証バグの原因箇所を特定してください

issue の文面と、関連しそうなソースファイルを同時に Claude の手元に持ってこさせる流れ。MCP サーバーが提供する resource は、テキストでも JSON でも構造化データでも何でも入っているので、組み合わせ方は自由です。

ステップ6: 動的に追加された resource を取り直す

セッション中に新しい issue が立った、ファイルが追加された、というときに、MCP サーバーが list_changed という通知を送ってくる仕組みがあります。Claude Code はこれを受け取ると、ListMcpResourcesTool を自動で叩き直して一覧を更新します。読者側は何もしなくていい。

ただし MCP サーバーの実装によっては list_changed を送ってこないものもあって、その場合はセッションを開き直さないと新しい resource が見えません。

つまり ListMcpResourcesTool は何をしてくれるのか

• やってくれる: つないでいる MCP サーバーが公開している resource、つまり読み取り専用の資料の一覧を Claude に渡す。@ オートコンプリートの候補生成の元データ
• やってくれない: resource の中身そのものを読むのは ReadMcpResourceTool の仕事。一覧取得と中身取得は分業
• 意味が薄い場面: MCP サーバーが tools しか実装していない、つまり resources 非対応の構成では、呼んでも空が返るだけで何の働きもしない

使いどころ3シナリオ

シナリオ1: GitHub の issue を Claude に読ませて原因調査させたいとき

OSS の不具合 issue が来た日、自分のフォークを Claude Code で開いて「@github:issue://456 を読んで該当ファイルを特定して」と頼む流れ。Claude は ListMcpResourcesTool で issue 番号の存在を確認して、ReadMcpResourceTool で本文を fetch、その文面を起点にコードを読み解いてくれます。issue を手動で開いてコピペする手間がなくなる場面。

シナリオ2: 設計ドキュメントを参照しながらコードを書かせたいとき

社内の Notion や docs サイトに API 設計書が置いてあって、それを MCP サーバー経由で公開しているケース。プロンプトで @docs:file://api/authentication と書くと、認証 API のドキュメントが Claude の手元に届く。「この設計通りにエンドポイントを実装して」と続ければ、設計と実装の食い違いを減らせます。

シナリオ3: 複数の resource を同時に突き合わせて整合性を確認したいとき

「@postgres:schema://users と @docs:file://database/user-model を比べて、テーブル構造とドキュメントが揃ってるかチェックして」みたいな依頼。DB の実スキーマと、ドキュメントの記述を Claude が同時に見て差分を指摘してくれる。プロンプト1本で「現物 vs ドキュメント」を照らし合わせる場面で効きます。

初心者が踏みやすい落とし穴

• つないだ MCP サーバーが resources を実装していないと、呼ぶ意味がない。tools だけ提供するタイプのサーバーだと、@ をタイプしてもローカルのファイル候補しか出てこない。サーバーの README で resources 対応の記載を必ず確認する
• @ の候補は MCP の resource とローカルファイルが同じメニューに混ざる。ファイル名がうろ覚えだと、近い名前の resource を誤選択するリスクがある。github: docs: といったサーバー名の頭文字で識別する癖をつける
• resource の中身は MCP サーバー側が一時的に貯めてる古いデータを返すことがある。GitHub MCP が直近のレートリミットで古い結果を返している、Notion の同期が数分遅れている、などの理由で「最新のはずなのに更新前の内容が来る」事故がある
• list_changed 通知を送らない MCP サーバーだと、セッション中に増えた resource が見えない。新しい issue を立てた直後に @ しても出てこないなら、一度 Claude Code を抜けて入り直す
• resource は読み取り専用なので、これ経由で書き込みはできない。issue を更新したい、ファイルを編集したい、というのは tools 側の仕事。混同しない
• 大量の resource を抱える MCP サーバーをつなぐと、一覧取得そのものが重くなる。数千ファイル規模の巨大プロジェクトに繋ぐなら、サーバー側で絞り込みが効くか、必要なフォルダだけ公開する設定があるか確認する
• URI 形式を間違えると Claude が「resource が見つかりません」と返してくる。@github/issue/123 ではなく @github:issue://123 がコロン＋ダブルスラッシュ形式。打ち間違いはオートコンプリートで防ぐのが安全

書き方

（読者が直接呼ぶ書式はない。Claude Code が内部で自動呼び出し。読者は @server:protocol://resource/path 形式で resource を指定して使う）

やってみるとこうなる

入力

> @github:issue://123 の内容を読んで、原因を推測してください

出力例

Claude が裏で ListMcpResourcesTool を呼んで「github サーバーに issue という種類の resource が存在する」ことを確認。続けて ReadMcpResourceTool で issue#123 の本文・コメント・ラベルを fetch して、その内容を踏まえた回答を返す

関連項目

• /readmcpresourcetool（準備中）
• /mcp-slash（準備中）
• MCP（エムシーピー）
• claude mcp（クロード・エムシーピー）

公式ドキュメント

https://code.claude.com/docs/en/tools-reference#listmcpresourcestool