MCP ツールの負荷を実測：26 個で毎回 $0.03

agent に MCP server を 1 台接続すると、何も処理しなくても API 呼び出しごとにコストが増える。GitHub server の 26 個のツールは、実際に使うかどうかにかかわらず、Claude Opus 4.8 を 1 回呼び出すたびに $0.0302 かかる。meter を確認するまで仕組みは見えず、負荷の大きさは接続するツール数よりも使用する model に左右される。ただし、その大半は回避できる。5 つの model family、実在する 5 台の MCP server、ツール数を 0 から 40 まで増やした合成データを使い、課金の全体像と caching や軽量化による削減効果を測定した。

TL;DR

• ツール定義は API を呼び出すたびに入力 token として再課金される。Claude Opus 4.8 では、小さなツール 1 個で 401 token だった。
• 同じ toolset でも、Claude の token 数は GPT-5.6 の 2.7 倍だった。実測値はツール 1 個あたり 173 対 64。
• 実在する GitHub MCP server の 26 ツールは、1 回あたり Opus 4.8 で $0.0302、Gemini 3.6 Flash で $0.0029。差は 10 倍ある。
• 明示的な caching により、毎回持ち回る block のコストは 10 分の 1 になる。ただし、最低 token 数に満たない toolset は cache できず、ツールを 1 個変更するだけでも block 全体が再課金される。

MCP server はどうやって入力 token になるのか？

処理は 3 段階あり、料金が発生するのは最後だけだが、API を呼び出すたびに繰り返される。まず対象範囲を整理する。MCP server が公開する primitive は tools、resources、prompts の 3 つ。このうち常時コストがかかるのは tools だけだ。API の tools parameter には、リクエストごとにすべての schema を含める必要がある。resources と prompts には専用の API field がなく、内容を実際に conversation へ取り込んだときだけ token を消費する。第 1 段階は MCP protocol そのものだ。agent client が JSON-RPC の tools/list で server に問い合わせ、schema を受け取る。これは session ごとに 1 回だけ実行され、model には送られない。第 2 段階では、client が schema を API の tools parameter に変換し、annotations や outputSchema など MCP 固有の field を除外する。ここも無料だ。第 3 段階で、provider がリクエストごとに schema を非表示の prompt text として展開する。API は stateless であり、model は利用可能なツールを記憶できないためだ。この展開後の text は、ツールを使うかどうかにかかわらず、毎回通常の入力単価で課金される。

最小構成で確認してみる。user message が「Reply OK」だけのリクエストは、Opus 4.8 で 11 prompt token だった。ここに、2 つの parameter と 1 行の description を持つ簡単な get_weather ツールを加えると、同じリクエストが 412 token になる。このツールを付けて送るたびに 401 token、$0.002 が上乗せされる。送信した JSON との差も大きい。ツールの JSON 自体は text 換算で約 130 token にすぎないが、provider が展開するとほぼ 3 倍になった。

ツール 1 個のコストは model ごとにどれくらい違うか？

多くのチームが想定する以上に model の影響が大きい。3 つの parameter と 1 行の description を持つ同一の合成 toolset を用意し、ツール数を 0 から 40 まで増やしながら 5 つの family に送信し、課金 token の増分を調べた。

同じツールでも差は 2.7 倍ある。この中では Claude の tool harness が最も冗長で、GPT-5.6 が最も簡潔だ。送信する JSON との比率も model によって逆方向に振れる。Claude の課金 token は、wire payload の byte 数を 4 で割った単純推定値の約 1.36 倍。一方、GPT-5.6 と Gemini はおよそ半分だった。tool block の token 数は family 間で共通ではない。schema 単位ではなく、model 単位で予算を見積もる必要がある。

実在する MCP server は 1 回あたりいくらかかるか？

公式 MCP repository にある 5 台の server を変更せず、標準の field mapping で変換した。API 呼び出しごとに持ち回る負荷の実測値は次のとおり。

最後の行から 2 つ分かる。Sequential-thinking が公開するツールは 1 個だけだが、5 つの family のうち 4 つでは、9 個のツールを持つ Memory より高い。1 個の description が非常に長いためだ。指標にすべきなのはツール数ではなく、展開後のサイズである。最上段も agent 開発者には意外な結果だ。GitHub の toolset を 10 回呼び出す agent episode に付け続けると、実際の処理を始める前に Opus 4.8 で $0.30、Gemini で $0.03 かかる。差は 1 桁ある。GLM 5.2 は Gemini の 2 倍を超える token が課金されるにもかかわらず、金額はさらに低い。list rate の安さが冗長な renderer を上回るため、token と金額は分けて見積もる必要がある。

agent は toolset のうち実際にどれくらい使うか？

呼び出し 1 回あたりで使うのはごく一部であり、これが負荷を割高に感じさせる。agent suite の tooling scenario では、一般的な episode の 3 回すべての呼び出しに 8 個の toolset を含めていたが、各呼び出しで実行されるツールは最大 1 個だった。1 個を使うために、毎回 8 個の schema を送っている。Opus 4.8 の実測 rate では、8 個の tool block は 1 回あたり約 1,674 token。episode 全体では、schema の持ち回りだけで約 5,000 token になる。tool-loop scenario は比較的効率がよく、3 個のツールがほぼ毎回使われる。それでも loop の 4 回から 5 回の呼び出しすべてで block が再送される。記録から得られた一般則は明確だ。1 回の呼び出しで使われるツールはほぼ 1 個以下であり、toolset の呼び出し単価は agent が実際に何をするかではなく、何を接続したかで決まる。

caching でツール負荷を吸収できるか？

適切な model なら大部分を吸収できるが、実測では 3 つの落とし穴があった。Claude Opus 4.8 では、tool block を独立した cacheable prefix として扱える。最後のツールに cache_control を付けると、20 ツールの block は最初に 1 回だけ書き込まれた。3,682 token に 1.25 倍の write premium がかかり、以降の呼び出しでは 0.1 倍で読み戻されたため、実質的な持ち回りコストは 90% 減った。Kimi K3 の自動 caching は設定不要で、さらに高い効果があった。2 回目の呼び出しでは、block 全体の 2,112 token のうち 2,048 token、つまり 97% が、通常どおり 256-token block 単位で cache から返された。GPT-5.6 の明示的な breakpoint でも、同じ family の初日測定で、write は 1.25 倍、read は 0.1 倍という同じ料金構成だった。Gemini の implicit cache は、これまでの測定結果と同様に、tool block を事前投入した 3 回の probe ですべて hit が 0 だった。ここでの割引は計画に組み込まず、得られれば得という扱いにすべきだ。

落とし穴の 1 つ目は最低 token 数だ。Claude で 2 個の tool block は約 655 token となり、cache の最低条件である 1,024 token に届かない。明示的に指定しても、小規模な toolset はまったく cache できない。この手段を使えるかどうかは、model ごとの最低 token 数で決まる。2 つ目は変更の影響だ。tool block は prompt の先頭に置かれるため、tool list を変更すると、その後ろの cache もすべて無効になる。実測では、Claude Opus 5 で cache 済みの 20-tool set にツールを 1 個追加すると、4,082-token block 全体が write premium 付きで再書き込みされた。session 中は tool list を固定しなければ、変更のたびに再書き込みコストが発生する。3 つ目は、この固定要件そのものだ。Anthropic の mid-conversation tool changes beta は、Opus 5 向けに document 化されており、cache を無効化せずに turn 間でツールを変更できるよう設計されている。ツールを多用する agent では注視すべき機能だ。

tool block 自体を小さくするには？

prose より先に parameter を削る。20-tool block の description を短い 1 節にすると 10% 削減できた。各ツールの parameter を 3 個から 1 個に減らすと 34% 削減でき、両方を行うと 44% 減った。3,768 token が 2,128 token になった。token の多くを占めるのは parameter schema の name、type、入れ子になった description だ。description だけを整え、schema を増やし続ける一般的な発想とは逆になる。

さらに効果が大きいのは、使わないものを接続しないことだ。MCP server を追加するたび、その server の block 全体がすべての呼び出しに加わる。設定を 1 行追加しただけで負荷が倍になることもある。client が filtering に対応しているなら、server のツールを一部だけ登録することで、負荷はおおむね比例して減る。GitHub server の 26 個から 5 個だけを残せば、server の平均的なツールサイズを基準にした推定で、Opus 4.8 の $0.0302 は $0.007 まで下がる。複数の family の model を使う場合は、前述の 2.7 倍差も考慮が必要だ。同じ agent を再見積もりせず Gemini から Claude に移すと、ツール持ち回りの token はほぼ 3 倍になる。

FAQ

MCP 自体に token コストはかかるか？

かからない。MCP protocol、discovery、JSON-RPC、ツール呼び出しの plumbing は model に触れず、料金も発生しない。コストが生じるのは、client が server の schema を API の tools parameter に渡し、provider が呼び出すたびに課金対象の prompt text として再展開するときだ。MCP が増幅するのは規模である。26 個のツールを 1 行で接続できるようになり、それ以降は 26 個の schema が毎回送られる。

使わないツールにもコストはかかるか？

かかる。使用するツールとまったく同額だ。model は呼び出し可能なツールを判断するため、毎回すべての schema を読む必要がある。agent-suite の記録では、1 回あたりに呼び出されるツールは最大 1 個だが、毎回 toolset 全体が課金されていた。接続済みで使われていない server は、持ち回りコストしか生まない。caching で割引はできるが、コスト自体をなくせるのは軽量化か切断だけだ。

MCP resources と prompts も tools と同じように token を消費するか？

消費しない。呼び出しごとの持ち回りコストがあるのは tools だけだ。tools parameter がリクエストごとにすべての schema を再送するためである。resources が課金されるのは、client が resource を読み込み、その内容を conversation に挿入したときだけだ。その時点で通常の入力となり、取得した document と同じ料金が適用される。同じ layering の原則も適用されるため、変化しやすい resource content は cache breakpoint の後ろに置く。prompt template も、呼び出して生成された text だけが課金される。接続した server にある未使用の resources と prompts は無料だ。MCP integration による課金を調査するときは、tools の数値を確認すべきである。

tool list を変更すると prompt cache は無効になるか？

全体が無効になる。tool block は prompt の先頭に展開されるため、変更すると block 自体と、その後ろにある cache がすべて再書き込みされる。実測では、ツールを 1 個追加しただけで 4,082-token block が 1.25 倍の premium 付きで再課金された。session ごとに tool list を固定し、変更はまとめて行うべきだ。Anthropic の mid-conversation tool changes beta は、Opus 5 でまさにこのコストをなくすために設計されている。

2026-07-31 に Synthorai gateway 経由で測定。5 つの model family を対象に、合成 tool ladder（0-40 tools、n=2）と実在する 5 台の MCP-server toolset を使用した。schema は公式 server から JSON-RPC の tools/list で取得。caching probe では salt 付き prefix と呼び出し単位の cache 明細を使用した。agent の利用率は、agent コスト調査の基礎となった suite 記録から算出。GPT-5.6 の caching multiplier は、初日に測定したコストガイドの値を引用している。金額は gateway meter から読み取った課金差額で、通常の入力 list rate に基づく。rate と展開動作は変わる可能性があるため、実際の利用記録でも確認してほしい。

← ブログに戻る