ListMcpResourcesTool / ReadMcpResourceTool（リストエムシーピーリソーシズツール・リードエムシーピーリソースツール）

MCPサーバーを1つ以上Claude Codeに繋いでいる人向け

Claude Codeに外部ツールを繋ぐ仕組みのことをMCPと呼ぶのですが、繋いだはいいものの「そのサーバーから何が読めるんだっけ？」「特定の1件だけ拾いたい時はどうやるんだっけ？」となりがちです。その2つの疑問に答える内蔵ツールがこのListMcpResourcesToolとReadMcpResourceToolです。

役割分担はシンプル。前者が「品揃え一覧」、後者が「指定した1件の中身を取りに行く係」。ペアで動きます。

噛み砕くと

初めて行く図書館をイメージしてください。受付で「ここって何の本がありますか？」と全カテゴリの一覧をもらうのがListMcpResourcesTool。一覧から「あ、この本読みたい」と1冊選んで「この本ください」と頼むのがReadMcpResourceToolです。

図書館がそもそも開いていなかったり、目録を作っていなかったら、両方とも空振りで終わります。MCPサーバー側が「resources機能」をサポートしているかどうかが前提条件です。

大事な前提：このツールはMCPサーバーが繋がっていて、かつ「resources対応」してないと何もしない

Claude Code本体にこのツールは内蔵されていますが、相手側のMCPサーバーが「うちはresources機能をサポートしてます」と宣言していないと、一覧を取りに行っても空っぽが返ってくるだけです。MCP仕様上、resources機能は「あってもなくてもいい付き合い方」になっていて、ツール機能だけ提供してresources機能は持っていないサーバーも普通にあります。

「@を打っても何も候補が出ない」時は、まずMCPサーバーの実装を疑うのが正解。Claude Code側を再起動しても直りません。

「料理ブログを新メンバーと立ち上げる初日」を例に、実際の手順を見る

状況はこう。前任者が抜けて、私が新メンバー1人と料理ブログを引き継ぐことになりました。引き継ぎメモはNotionにバラバラ、未対応の課題はGitHub Issuesに散らばっている。これをClaude Codeに参照させながら作業を始めたい。

ステップ1: NotionとGitHubのMCPサーバーを繋いだ状態でClaude Codeを開く

事前にNotion用とGitHub用のMCPサーバーをclaude mcp addで登録してあるとします。Claude Codeを起動すると、起動直後にこの2つのMCPサーバーが裏で立ち上がります。

ステップ2: プロンプトに@と打って候補を確認する

プロンプトに私が@と打った瞬間、Claude CodeはListMcpResourcesToolを裏で叩いて、繋がっているMCPサーバーが公開しているリソース一覧を引っ張ってきます。これがオートコンプリート候補に並びます。

@

↓ オートコンプリート候補例

@github:issue://1   料理写真の差し替え依頼
@github:issue://2   レシピカードの著作権確認
@notion:page://handover-overview   引き継ぎ全体メモ
@notion:page://recipe-style-guide   レシピ表記ルール

裏側で動いているのがListMcpResourcesTool。ユーザーが直接「ListMcpResourcesToolを実行して」と打つことはまずありません。@のオートコンプリートが表の顔です。

ステップ3: 必要なリソースを@付きでプロンプトに混ぜる

引き継ぎ全体メモと、ピックアップした2件のissueを指定してプロンプトを書きます。

@notion:page://handover-overview を読んで全体像を掴んだあと、
@github:issue://1 と @github:issue://2 を優先度つけて整理してください。

送信すると、Claudeは各@参照ごとにReadMcpResourceToolを呼び出して、対応するURIの中身を取りに行きます。取れた中身はそのメッセージへの添付ファイル扱いで一緒に渡されます。

ステップ4: Claudeが能動的に追加リソースを探したい時も同じツールを使う

ここで初心者がやりがちな勘違いがあります。「@で指定したリソースしか読まないんでしょ？」と思いがち。実は違います。

私が@で指定しなくても、Claudeが作業中に「Notionにもっと関連メモがありそうだな」と判断したら、自分でListMcpResourcesToolを呼んでNotion側に何があるか確かめにいき、必要ならReadMcpResourceToolで個別ページを読みにいきます。能動的調査の窓口でもあるわけです。

ステップ5: 同じプロトコル指定でも、サーバーごとに記法が違う

ここが地味につまずきポイント。@server:protocol://resource/pathのprotocol部分はサーバー実装側が自由に決めています。

• GitHub MCPサーバー: issue://123、pull://45 など
• Notion MCPサーバー: page://abc-123、database://xyz など
• PostgreSQL MCPサーバー: schema://users、table://orders など

同じ「issue」を指す書き方が共通化されているわけではありません。サーバーごとの仕様。とはいえ、自分でこの記法を暗記する必要はなくて、@を打ってオートコンプリートに出てくる候補をそのまま選べばOKです。

ステップ6: 反映確認

Claudeから整理結果が返ってきます。「issue#1は優先度高、写真差し替えは公開前に必須」「issue#2は法務確認が要るので保留」みたいに、引き継ぎメモとissueの中身を突き合わせた回答が出てくるはず。

これで初日の状況把握が30分くらいで終わります。Notionタブを開いてGitHubタブを開いて、と画面を行ったり来たりしないで済むのが体感メリット。

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

• やってくれる: 繋がっているMCPサーバーが公開しているリソースの一覧取得、URI指定での個別リソース取得、Claudeが能動的に「サーバーが何を持ってるか調べたい」時の調査窓口
• やってくれない: 外部ウェブサイトの取得はWebFetch側、ローカルファイルの読み取りはRead側、resources機能を持たないMCPサーバーから何かを引っ張ること（仕様上できない）
• 意味が薄い場面: 繋いでいるMCPサーバーが「ツール提供のみでresources非対応」のとき。一覧を叩いても空っぽしか返ってこない

使いどころ3シナリオ

シナリオ1: 新メンバーがOSSプロジェクトに参加した初日、Linear起票の対応リスト＋Notionのオンボーディング資料を横断で読みたいとき

LinearもNotionもMCPサーバーを繋いでおけば、@linear:issue://... と @notion:page://onboarding を同じプロンプトで参照できます。両方の中身を見比べながら「今日触ってよさそうな第1課題はこれ」とClaudeに選ばせる、というのが現実的な初日の使い方。タブを行き来する時間が消えます。

シナリオ2: 既存サービスのDBスキーマ変更を検討するとき、PostgreSQLの実テーブル定義とNotionの仕様書を1セットで読ませる

PostgreSQL MCPサーバーのschema://usersとNotionのpage://users-specを同時に参照させて、「仕様書とDBの実体がずれている箇所だけ抽出して」と頼む。差分の手動目視は地獄なので、ここはMCPリソースの一番美味しい活用シーン。私の中では一番使う場面です。

シナリオ3: バグ報告対応で、GitHub issueの本文、関連PR、Sentryのエラーレポートを1プロンプトに集約したいとき

GitHub MCPサーバーの@github:issue://456と@github:pull://457、Sentry MCPサーバーの@sentry:event://...を同じプロンプトに並べて投げると、Claudeが3つを突き合わせて「ここが再現条件、ここが該当コード変更、ここがログでの実エラー」と整理してくれます。コピペで一個一個渡すのと比べて、私は体感で2割くらい時間が浮いてる感じ。

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

• MCPサーバーがresources機能をサポートしていないと一切動かない。MCP仕様上resourcesは付けるかどうか実装者の自由。@を打って何も出ない時は、Claude Codeの設定じゃなくMCPサーバー側の実装を疑う
• @server:protocol://resource/pathのprotocol部分はサーバーごとに違う。GitHubはissue://、PostgreSQLはschema://、Notionはpage://、と各サーバーが好きに決めている。サーバーが何のスキームを公開しているかはListMcpResourcesToolで確かめるか、@のオートコンプリートで確認するのが早い
• WebFetchやReadと混同しない。外部のウェブURLはWebFetch、自分のパソコン内のファイルはRead、MCPサーバー経由で公開されたリソースだけがReadMcpResourceTool。役割が3つに分かれていることを掴むと混乱しない
• ユーザーが直接「ListMcpResourcesToolを実行して」と打つことはない。これらは内部ツールで、Claudeが必要に応じて自動で呼ぶ。ユーザーから見える表の顔は@のオートコンプリートだけ
• サーバー認証は別途必要。permission required: Noはツールの実行許可の話で、GitHubのissue内容を読むにはGitHub MCPサーバー側にトークンを渡しておく必要がある。「ツール許可が要らない＝何でも読み放題」ではない
• 参照のたびにフェッチされる前提で書く。公式の説明だと「@で参照したリソースは添付ファイルとして自動取得される」。毎回フェッチされる前提で計画したほうが安全。「使い回し保存しておいて2回目は省略」の仕様は公開されていない以上、参照1回ごとにMCPサーバーへ問い合わせが走ると思っておく
• 同じリソースの巨大な中身を毎回貼ると会話が膨らむ。たとえばNotionの100ページ分のデータベースを毎ターン@参照すると、Claudeに渡されるテキスト量が一気に増える。「最初に1回参照して、以降は会話の流れで参照する」程度に止めるとコンテキストが暴れない

書き方

ユーザー側からは @ を打って候補から選ぶか、@server:protocol://resource/path 形式で直接書く。例: @github:issue://123 / @notion:page://handover-overview / @postgres:schema://users。protocolの種類（issue/page/schema 等）はMCPサーバー実装ごとに違う。

やってみるとこうなる

入力

@notion:page://handover-overview を読んで全体像を掴んだあと、@github:issue://1 と @github:issue://2 を優先度つけて整理してください。

出力例

ListMcpResourcesTool（一覧取得）の結果例:
- @github:issue://1   料理写真の差し替え依頼
- @github:issue://2   レシピカードの著作権確認
- @notion:page://handover-overview   引き継ぎ全体メモ

ReadMcpResourceTool（個別取得）の結果例:
URI: @github:issue://1
本文: 「公開前に写真が一部商用利用NGのものに差し替え必要。優先度高」
ラベル: priority-high, content
担当: 未割当

関連項目

• MCP（エムシーピー）
• WebSearch / WebFetch（ウェブサーチ・ウェブフェッチ）
• Read（リード）
• AskUserQuestion（アスクユーザークエスチョン）
• ToolSearch（ツールサーチ）

公式ドキュメント

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