MCP Tokenを減らす「ツールにしない」設計：ResourcesとPromptsの使い分けと費用計算【2026年版】

最終更新：2026年10月26日 ／ 対象：MCP仕様 2026-07-28（tools・resources・prompts）、Claude Code、VS Code（GitHub Copilot）、Cursor、Claude APIのMCPコネクタ、Claude Sonnet 5.5の料金

MCPのトークン消費（MCP Token）を減らす話は、たいてい「サーバーが出すものはすべてツール」という前提で進みます。しかしMCPのサーバー側の機能（プリミティブ）は3つあり、そのうちResources（リソース）とPrompts（プロンプト）は、誰かが使うまでモデルのコンテキストに何も載せません。この記事では、データをツールからリソースへ、手順の説明をサーバーの説明文からプロンプトへ移すと、どんなときに実際にトークンが減るのかを解説します。自分の環境で計算し直せる3つの費用計算と、各クライアントの対応状況の表も載せています。

なお、ここでの「トークン」はLLMのトークン（コンテキストと課金の単位）のことで、APIキーやOAuthのアクセストークンのことではありません。

結論（30秒で読める要約）

• MCP仕様（2026-07-28）では、ツールは「モデルが制御」、リソースは「アプリケーションが制御」、プロンプトは「ユーザーが制御」と定義されています。モデルが呼ぶかどうか判断するために定義をコンテキストに載せる必要があるのは、ツールだけです。
• ユーザーが添付したリソースは、モデルとのやり取りを1往復省けます。ツールだと、モデルがまずデータを要求し、その結果を付けてコンテキスト全体がもう一度送られます。筆者の計算（コンテキスト2万トークン、文書3,000トークン、Claude Sonnet 5.5）では、ツール経由の方が1回あたり入力が20,110トークン多くなります。キャッシュなしで約0.041ドル、先頭部分がキャッシュヒットすれば約0.0027ドルの差です。
• ツールを最初から読み込むクライアントでは、データを返すだけのツールでも毎回定義のトークンがかかります。1個600トークン程度の読み取り専用ツール5個で1リクエストあたり約3,000トークン、40リクエストのセッションで12万トークンです。リソースなら、添付されるまでコンテキスト上のコストはゼロです。
• プロンプトで得をするのは、毎回のセッションでは使わない場合だけです。一度呼び出すと、その文面は会話に残り、以降のリクエストで毎回送られます。サーバーの説明文（instructions）と同じです。
• クライアントの対応はまちまちです。Claude CodeとVS Codeはリソースとプロンプトに対応しています。Cursorは公式ドキュメント上は両方「対応」ですが、2026年2月のフォーラムではリソースの不具合が報告されています。Claude APIのMCPコネクタはツール呼び出しのみの対応です。
• 現実的には併用が一番です。データはリソースとして出し、リソースを添付できないクライアントやエージェント向けに、汎用の読み取りツールを1つだけ用意します。

目次

1. MCPのツール・リソース・プロンプトとは
2. それぞれのどこでMCPのトークンを使うか
3. 費用計算1：リソースで省ける1往復
4. 費用計算2：データ取得だけのツールの定義コスト
5. 費用計算3：プロンプトとサーバー説明文の比較
6. クライアント別のリソース・プロンプト対応（2026年10月時点）
7. 2026-07-28版の仕様で変わったこと
8. 判断表：ツール・リソース・プロンプトのどれにするか
9. 実装例：リソースと読み取りツール1つの組み合わせ
10. チェックリスト
11. よくあるハマりどころ
12. NodeFlareならこう解決できる
13. FAQ

1. MCPのツール・リソース・プロンプトとは

MCPのツール・リソース・プロンプトは、MCPサーバーが公開できる3つのプリミティブで、違いは「いつ使うかを誰が決めるか」です。MCPの仕様は、それぞれを次のように定義しています。

プリミティブ	誰が制御するか	中身	モデルへの届き方
ツール	モデル（model-controlled）	モデルが呼び出せる関数	定義がモデルに送られ、呼び出し後に結果が返る
リソース	ホストアプリ（application-driven）	URIで識別されるデータ（ファイル、スキーマ、レコードなど）	ユーザーやアプリが選んだときに、中身が会話に添付される
プロンプト	ユーザー（user-controlled）	サーバーが用意したメッセージのテンプレート	ユーザーが呼び出したときにメッセージが挿入される。多くはスラッシュコマンドの形

仕様では、リソースは「ホストアプリケーションが必要に応じてコンテキストへの取り込み方を決める」ものとされ、例としてピッカーや検索画面が挙げられています。プロンプトは「ユーザーが明示的に選んで使うことを想定してサーバーからクライアントへ公開される」ものです。

トークンの話は、この違いに尽きます。モデルがツールを呼ぶと判断するには、ツールの定義を見ている必要があります。一方、リソースやプロンプトは、人かアプリが「使う」と決めるまで、モデルが見る必要はありません。

2. それぞれのどこでMCPのトークンを使うか

どのプリミティブにも、固定コスト（使わなくても毎リクエストかかる分）と、利用コスト（使ったときにかかり、会話に残る限り以降も毎回送られる分）があります。

コスト	ツール	リソース	プロンプト
毎リクエストの固定コスト	名前・説明・inputSchema（ツール検索で遅延読み込みされない場合）	コンテキスト上はなし（クライアントが独自の一覧・読み取りツールを足すことはある）	コンテキスト上はなし
1回使うごとに増えるモデルへのリクエスト	1回（モデルがツール呼び出しを出し、結果を付けて再送）	ユーザーが添付した場合はなし	なし
利用コスト	呼び出しの引数＋結果	リソースの中身	プロンプトのメッセージ（埋め込みリソースを含む）
使った後も履歴に残るか	残る	残る	残る

見落としやすい点が2つあります。1つ目は、リソースの中身のトークン数は、同じ中身をツールの結果として返した場合と変わらないことです。リソースにしてもデータは小さくなりません。2つ目は、会話に入ったものはすべて、以降のリクエストで再送されることです。この増え方は長いセッションで古いツール結果を消す方法で詳しく扱っています。

つまり、リソースとプロンプトで減らせるのは「定義の固定コストがないこと」と「1往復が不要なこと」の2つだけです。

3. 費用計算1：リソースで省ける1往復

モデルがツールでデータを取りに行くと、クライアントはモデルに2回リクエストを送ります。1回目はツール呼び出しで終わり、2回目で結果を含めたコンテキスト全体を送り直します。ユーザーがリソースを添付した場合は、中身が1回目に入るので2回目は要りません。

前提（筆者が置いた例で、計測値ではありません）：

• C＝すでにコンテキストにある20,000トークン（システムプロンプト、ツール定義、履歴）
• u＝ユーザーのメッセージ50トークン
• o＝モデルのツール呼び出し60トークン
• R＝文書3,000トークン
• モデル：Claude Sonnet 5.5。入力100万トークンあたり2ドル、出力10ドル、キャッシュ読み取り0.10ドル（Anthropic料金ページ、2026年10月時点）

経路	1回目の入力	2回目の入力	入力の合計	追加の出力
ツール呼び出し	C＋u＝20,050	C＋u＋o＋R＝23,110	43,160	60（ツール呼び出し）
リソースを添付	C＋u＋R＝23,050	なし	23,050	0

ツール経由では、1回あたり 43,160−23,050＝20,110トークン（C＋u＋o）の入力が余分にかかります。

キャッシュ	1回あたりの差額	1,000回あたり
キャッシュなし	20,110×2ドル÷100万＋60×10ドル÷100万＝0.0402＋0.0006 ≒ 0.041ドル	約40.82ドル
先頭部分がキャッシュヒット	20,050×0.10ドル÷100万＋60×2ドル÷100万＋60×10ドル÷100万 ≒ 0.0020＋0.0001＋0.0006 ≒ 0.0027ドル	約2.73ドル

キャッシュ書き込みの費用は含めていません。プロンプトキャッシュが効いていれば、この1往復は金額としては小さく、主な差は待ち時間と出力トークンです。キャッシュが効いていないと、1回の参照にかかる入力費用がほぼ2倍になり、Cが大きいほど差は広がります。

この計算が当てはまるのは、どのデータが必要かを人かアプリがすでに分かっている場合だけです。モデルが自分で探す必要があるならツールが必要です（クライアント組み込みのリソース読み取りツールを使う場合も、1往復が発生します）。

4. 費用計算2：データ取得だけのツールの定義コスト

get_schema、get_style_guide、get_api_reference のように、読み取り専用のデータをツールとして出しているサーバーはよくあります。ツールを最初から読み込むクライアントでは、こうした定義が、使わないセッションでも毎リクエスト送られます。

Anthropicが2025年11月に公開したツール検索の記事にはサーバーごとの数値があり、ツール1個あたりのおおよその幅が分かります（割り算は筆者）。

サーバー（Anthropicの例）	ツール数	概算トークン	1ツールあたり
Sentry	5	約3K	約600
GitHub	35	約26K	約743
Slack	11	約21K	約1,909

読み取り専用ツール5個を持つドキュメント用サーバーを、この幅の下限（1個約600トークン、計約3,000トークン）で、40リクエストのセッションに当てはめます。

• 1セッションの定義トークン：3,000×40＝120,000
• Sonnet 5.5でキャッシュなし：120,000×2ドル÷100万＝1セッション0.24ドル
• キャッシュヒット：120,000×0.10ドル÷100万＝1セッション0.012ドル
• 5個のリソースにした場合：コンテキスト上の固定コストは0トークン

ただし、ツール検索があると話が変わります。Claude Codeのドキュメントには、ツール検索（既定で有効）では「セッション開始時に読み込むのはツール名とサーバーの説明文だけ」とあります。この場合、データ取得だけのツールの固定コストは小さく、リソースにする主な理由は3章の1往復になります。ツールを最初から読み込むクライアントや、遅延読み込みを使わずにAPIで自作したエージェントでは、上の定義コストがそのままかかります。どのクライアントが最初から読み込むかはクライアント別のMCPツール上限にまとめています。

5. 費用計算3：プロンプトとサーバー説明文の比較

「リリースの手順」「マイグレーションのレビュー方法」のような作業手順は、サーバーの説明文（instructions）や長いツール説明に書かれがちです。Claude Codeではサーバーの説明文はセッション開始時に読み込まれるので、毎リクエストかかります。プロンプトなら、ユーザーが呼び出したリクエストからしかかかりません。

前提：800トークンの作業手順、40リクエストのセッション、プロンプトをk回目のリクエストで呼び出す。

手順を置く場所	1セッションのトークン	計算式
サーバーの説明文	32,000	800×40
プロンプト（1回目で呼び出し）	32,000	800×(40−1+1)
プロンプト（31回目で呼び出し）	8,000	800×(40−31+1)
プロンプト（呼び出さない）	0	－

セッションのうち割合pでその手順を序盤に使うなら、期待値はおよそ32,000×pトークンです。毎回は使わない手順なら、プロンプトにした方がトークンは減ります。毎回必ず使うなら、プロンプトと説明文の費用は同じで、ユーザーが何もしなくてもモデルが読める分、説明文の方が便利です。

「請求に関する質問にはこのサーバーを使う」のような短い案内はサーバーの説明文に残し（ツール検索がこれを使います）、長い手順はプロンプトへ移すのがよい分け方です。

6. クライアント別のリソース・プロンプト対応（2026年10月時点）

リソースやプロンプトを使えないクライアントでは、移しても何も減りません。各社の公式ドキュメントで現在確認できる内容は次のとおりです。

クライアント	ツール	リソース	プロンプト	出典
Claude Code	対応（ツール検索が既定で有効）	対応。@ を入力して選ぶか、@server:protocol://resource/path で指定。参照すると自動で取得され添付される。リソースの一覧・読み取り用のツールもモデルに自動で渡される	対応（コマンドとして表示）	Claude Code公式：MCP
VS Code（GitHub Copilot）	対応	対応。Add Context > MCP Resources、またはコマンド「MCP: Browse Resources」	対応。/<server>.<prompt> と入力	VS Code公式：MCP servers（2026年10月21日更新）
Cursor	対応	ドキュメント上は「Supported」。2026年2月のフォーラムではリソースが動かないとの報告があり、「既知の不具合」との返信あり	ドキュメント上は「Supported」	Cursor公式：MCP、Cursorフォーラム
Claude APIのMCPコネクタ	対応	非対応	非対応	Claude公式：「現在サポートしているのはツール呼び出しのみ」

実務上の影響は2つあります。

• Claude Codeにはリソース用の組み込みツールがあるので、モデルが自分でリソースを取りに行くこともあります。その場合はツールと同じく1往復かかります。3章の節約が当てはまるのは、ユーザーが添付したときです。
• 利用者にAPIベースのエージェントがいるなら、ツール経由の取得手段は残す必要があります。Claude APIのMCPコネクタはリソースとプロンプトをまったく扱いません。

7. 2026-07-28版の仕様で変わったこと

2026-07-28版で3つのプリミティブの役割は変わっていませんが、実装に関わる細部がいくつか変わりました。

変更点	2025-11-25版	2026-07-28版
一覧のキャッシュ	記載なし	resources/list、resources/templates/list、prompts/list の結果に ttlMs と cacheScope を付けられる
一覧に含める内容	記載なし	接続ごとに変えてはいけない（MUST NOT）が、リクエストの認可情報によって変えてよい（MAY）
リソースの購読	resources/subscribe リクエスト	resourceSubscriptions を指定した subscriptions/listen
リソースが見つからないとき	-32002	-32602（Invalid Params）。クライアントは -32002 も受け付けるべき（SHOULD）
読み取り前の追加入力	なし	resources/read と prompts/get が InputRequiredResult を返せる（複数往復リクエスト）

いずれも、モデルのコンテキストにトークンを足すものではありません。一覧のキャッシュで減るのはプロトコルの通信量で、LLMのトークンではありません。認可の規定は間接的に効きます。呼び出し元のスコープで許されたリソースとプロンプトだけを返せるので、リソースのピッカーやクライアントが作る一覧を短く保てます。

8. 判断表：ツール・リソース・プロンプトのどれにするか

選び方の基準は、「必要になった時点で、それが必要だと分かっているのは誰か」です。

公開したいもの	必要だと分かっているのは誰か	向いているプリミティブ	トークン面の理由
副作用のある操作（作成・更新・送信）	モデル	ツール	ツールにするしかない。定義を削って対応する
作業の途中でモデルが判断する検索・最新情報の取得	モデル	ツール	モデルが選ぶ必要がある
ユーザーが話題にしたい特定の文書・スキーマ・チケット・ファイル	ユーザー	リソース	定義コストがなく、1往復も不要
大きな静的資料（APIドキュメント、スタイルガイド）	ユーザー（ときどきモデル）	リソース＋汎用の読み取りツール1つ	固定コストがツール1個分で済む
ツールが生成した大きなデータ	モデル	resource_link を返すツール	必要なときだけ中身を読み込む
長く、繰り返し使う手順	ユーザー	プロンプト	使ったセッションでしかかからない
いつこのサーバーを使うかの短い案内	全員・毎セッション	サーバーの説明文	短く、ツール検索が参照する

大きなデータを返すツールについては、MCPツールのレスポンスを小さくする方法で resource_link やページングを解説しています。

9. 実装例：リソースと読み取りツール1つの組み合わせ

次のTypeScriptの例（MCP TypeScript SDKの書き方に沿ったスケッチです。正確なAPIはお使いのバージョンのSDKドキュメントで確認してください）は、ドキュメントのフォルダをリソースとして公開し、リソースを添付できないクライアント向けに小さなツールを1つ足しています。

// 文書ごとの "get_x_doc" ツールをN個作る代わりに、リソーステンプレートを1つ
server.registerResource(
  "docs",
  new ResourceTemplate("docs://{slug}", { list: listDocs }),
  { title: "Product docs", mimeType: "text/markdown" },
  async (uri, { slug }) => ({
    contents: [{ uri: uri.href, mimeType: "text/markdown", text: await readDoc(slug) }],
  })
);

// リソース非対応のクライアントやエージェント向けの汎用ツールを1つ
server.registerTool(
  "read_doc",
  {
    description: "Read one product doc by slug, for example 'auth' or 'billing'.",
    inputSchema: { slug: z.string() },
  },
  async ({ slug }) => ({ content: [{ type: "text", text: await readDoc(slug) }] })
);

// 長い手順はサーバーの説明文ではなくプロンプトに
server.registerPrompt(
  "release_checklist",
  { title: "Release checklist", argsSchema: { version: z.string() } },
  ({ version }) => ({
    messages: [{ role: "user", content: { type: "text", text: releaseSteps(version) } }],
  })
);

文書ごとにツールを作る場合と比べて、文書がいくつ増えても固定コストは小さなツール定義1個分のままです。

効果を測るには、Anthropicのトークン数カウント用エンドポイント（/v1/messages/count_tokens）に、変更前と変更後のツール一覧で同じリクエストを送って比べます。Claude Codeでは /context でセッション開始時に何が読み込まれたかを確認できます。

10. チェックリスト

• [ ] すべてのツールが、副作用を持つか、モデルが呼ぶかどうかを判断する必要があるものになっている
• [ ] 読み取り専用の参照データはリソース（またはリソーステンプレート）として公開している
• [ ] ツールしか使えないクライアント向けの汎用読み取りツールは多くても1つにしている
• [ ] 長い手順はプロンプトにし、サーバーの説明文には短い案内だけを書いている
• [ ] 大きなツール出力は中身を直接返さず resource_link を返している
• [ ] 利用者が使う各クライアントで、リソースとプロンプトの対応を確認した
• [ ] リソースが見つからないときは -32602 を返し（2026-07-28版）、クライアント側は -32002 も受け付ける
• [ ] 変更前後のツール一覧を count_tokens または /context で測った

11. よくあるハマりどころ

症状	原因	対処
一部の利用者にリソースが表示されない	クライアントがツールのみ対応（例：Claude APIのMCPコネクタ）か、リソースに不具合がある	汎用の読み取りツールを1つ残しておく
リソースに移したのにトークンが減らない	モデルがクライアントの一覧・読み取りツールで取りに行っており、1往復が戻っている	必要なものが分かっているときは、@ や Add Context で添付するよう利用者に案内する
セッション中にトークン消費が増え続ける	添付したリソースもツール結果と同じく履歴に残る	古いコンテキストを消すか要約する（長いセッションの記事を参照）
プロンプトのせいで毎セッション高くなった	結局すべてのセッションの最初に呼び出している	使わないセッションがある場合だけプロンプトにする。毎回使うなら文面を短くする
1つのプロンプトが巨大な埋め込みリソースを読み込む	埋め込みリソースは中身をすべてメッセージに入れる	プロンプト内では resource_link を使う
2026-07-28版に上げた後、リソースの読み取りが失敗する	「見つからない」のエラーコードが -32002 から -32602 に変わった	サーバーとクライアントの両方でエラー処理を更新する

12. NodeFlareならこう解決できる

NodeFlareは、GitHubリポジトリからMCPサーバーを動かし、その前段にプロキシを置くサービスです。以下のトークン関連の設定はこのプロキシが適用するもので、ドキュメントにはサーバーのコードには手を加えないと書かれています。

課題1：ツールしか使えないクライアントのためにデータ取得用のツールを残す必要があり、それが最初から読み込まれる。 → tool_search_mode を有効にします。ツール一覧（tools/list）を search_tools(query) と call_tool(name, args) の2つのメタツールに畳み込むので、ツールを最初から読み込むクライアントでも、見える定義は全ツール分ではなく2つになります。検索は字句検索で、GEMINI_API_KEY を設定すると意味検索になります。あわせて tool_schema_slim を使うと、500文字を超えるツール説明を切り詰めます。名前と入力スキーマはそのままです。

課題2：モデルが文書を1件ずつツールで読み、そのたびに1往復かかる。 → Code Execution（tool_code_mode）を有効にします。run_code と search_tools が公開され、モデルが tools.* を呼ぶJavaScriptを書き、サンドボックスで実行します。複数の読み取りを1回のツール呼び出しにまとめられ、返す内容もスクリプトで絞り込めます。既定値は実行タイムアウト600秒、1回あたりのツール呼び出し上限50回です。

課題3：呼び出し元が使えないツール・リソース・プロンプトまで見えてしまう。 → tool_list_filter_by_scope を有効にすると、tools/list には呼び出し元の資格情報で呼べるツールだけが表示されます。リソースとプロンプトにも、ツールと同じ認証・スコープ・キャッシュ・フィルタが適用されます。resources/read と prompts/get は tools/call と同じようにスコープで管理され、スコープの例として resources:read:<uri> と prompts:get:<name> が挙げられています。なお、トークン最適化の4つの設定は、ドキュメント上はツールを対象とした説明になっています。

最小の始め方：

1. ダッシュボードでGitHubリポジトリを指定します（モノレポのサブディレクトリも可）。ランタイム・トランスポート・起動コマンドは自動で検出・入力されます。
2. NodeFlareがビルドし、MCPの initialize に正しく応答することを確認してから、認証付きのHTTPS URLを発行します。
3. URLとAPIキーをMCPクライアントに設定し、上の設定を有効にします。

1サーバーまで無料で試せます：nodeflare.tech

13. FAQ

MCPのリソースはツールよりトークンが少ない？

中身そのもののトークン数は同じです。リソースのテキストは、同じテキストをツールの結果として返した場合と同じだけトークンを使います。リソースで減るのは、毎リクエストの定義が不要になる分と、ユーザーが添付したときにモデルが取りに行く1往復が不要になる分です。

MCPのリソースは自動でコンテキストに読み込まれる？

既定では読み込まれません。仕様上、リソースの扱いはホストアプリが決めます。Claude Codeでは @ で参照したときにリソースが自動で取得され、添付としてコンテキストに入ります。Claude Codeはリソースの一覧・読み取り用のツールもモデルに渡すので、モデルが自分で取りに行くこともあります。

ツールではなくMCPリソースを使うべきなのはどんなとき？

データが読み取り専用で、スキーマ・文書・チケットのように、どれが欲しいかを人が分かっていることが多い場合です。何を取得するかをモデルが判断する必要がある場合や、何かを変更する操作の場合はツールにします。

MCPのプロンプトはトークンを消費する？

呼び出されてから消費します。プロンプトの一覧はモデルに送られません。ユーザーがプロンプトを実行すると、そのメッセージが会話に入り、ほかのメッセージと同じく以降のリクエストで毎回送られます。

CursorはMCPのリソースに対応している？

CursorのMCPドキュメントでは、リソースとプロンプトはどちらも「Supported」と書かれています。ただし2026年2月のフォーラムでは、リソースが動かないという報告と、subscribe の扱いに関する「既知の不具合」だという返信がありました。Cursorでリソースに頼る前に、お使いのバージョンで動作を確認してください。

Claude APIのMCPコネクタはリソースやプロンプトに対応している？

対応していません。Anthropicのドキュメントには、MCPコネクタが現在サポートしているのはツール呼び出しのみと書かれています。コネクタを使うエージェントには、必要なデータを取得できるツールを用意してください。

ツール検索があればリソースは不要？

ツール検索に対応したクライアントでは、ツールの固定コストはほとんどなくなります。Claude Codeはセッション開始時にツール名とサーバーの説明文だけを読み込みます。それでもリソースには、ユーザーが添付すれば1往復を省ける利点があり、ツールを最初から読み込むクライアントでも効果があります。

resource_linkとリソースの違いは？

resource_link は、ツールやプロンプトが返すコンテンツの一種で、中身を埋め込まずにURIでリソースを指すものです。クライアントは必要になったときに読み込めます。リソースはデータそのもので、resources/list で一覧を取り、resources/read で読み込みます。

作業手順はサーバーの説明文とプロンプトのどちらに書くべき？

短い案内はサーバーの説明文に書きます。毎セッション読み込まれ、ツール検索にも使われるからです。長い手順はプロンプトにします。使わないセッションではコストがかからないからです。この記事の例では、800トークンの手順は、40リクエストのセッションで説明文なら32,000トークン、使われないプロンプトなら0トークンです。

2026-07-28版のMCP仕様でリソースは変わった？

細部が変わりました。一覧の結果にキャッシュのヒント（ttlMs、cacheScope）を付けられるようになり、購読は subscriptions/listen に移り、リソースが見つからないときのエラーは -32602 になりました。一覧を呼び出し元の認可に応じて変えてよいことも明記されました。いずれも、リソースがモデルのコンテキストで使うトークン数は変えません。

まとめ

MCPのトークン消費を減らす方法は、ツールを削ることだけではありません。モデルに定義を見せる必要があるのはツールだけです。ユーザーが選ぶ読み取り専用のデータはリソースにすると、定義のトークンと1往復を省けます。長い手順はプロンプトにすると、使わないセッションではコストがかかりません。注意点は、クライアントの対応状況と、履歴に残って増えていくことです。ツールしか使えないクライアント向けに読み取りツールを1つ残し、添付したものは会話に残り続けることを覚えておいてください。サーバーの構成を変える前に、上の3つの計算を自分のコンテキストの大きさ、文書の大きさ、セッションの長さで計算し直してみてください。

参考資料

• MCP仕様 2026-07-28：Resources
• MCP仕様 2026-07-28：Prompts
• MCP仕様 2025-11-25：Resources
• Claude Code公式：Connect Claude Code to tools via MCP
• VS Code公式：MCP servers
• Cursor公式：Model Context Protocol ／ Cursorフォーラム：MCP resources support
• Claude公式：MCP connector ／ Pricing
• Anthropic Engineering：Introducing advanced tool use（2025年11月24日）
• 関連記事：MCPのAPIキー管理：発行・スコープ・ローテーション・失効
• NodeFlare：ドキュメント ／ 料金