MCPのツール定義のトークンを計測して削る方法：説明文とinputSchemaの書き直し実例【2026年版・実測】

最終更新：2026年10月16日／対象：MCP仕様 2026-07-28（ツール定義）、Claude CodeのMCP説明文の上限、Anthropicのツール定義ガイド、Claude 5.5の料金

MCPのトークン消費（MCP token usage）は、最初のメッセージを送る前から始まっています。サーバーが公開するツールは、名前・説明文・inputSchema の形でリクエストのたびにモデルへ送られるからです。この記事はMCPサーバーを作る人・運用する人向けに、ツール定義1つあたりのトークンを計測する方法、定義のどこが重いのか、そしてモデルに必要な情報を削らずに約4分の1まで軽くする書き直し方を、実測値つきで解説します。

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

説明文よりスキーマの方が重いことが多いです。よくある自動生成の create_issue ツールを計測したところ、定義全体のトークンのうち inputSchema が64%、説明文は32%でした。
4段階の書き直しで、このツールは 937トークンから237トークン（−75%） になりました。スキーマのメタ情報（$schema、プロパティごとの title、examples）を外す、null許容の anyOf を普通の任意項目にする、パラメータ説明で型や列挙値を繰り返さない、ツール説明を3〜4文に書き直す、の4つです。
説明文を短くするだけでは足りません。同じツールで説明文を500文字で切った場合の削減は24%でした。スキーマには手が入らないためです。
意味は削らないこと。Anthropicは詳しい説明文を「ツール性能を左右する圧倒的に重要な要素」とし、1ツールにつき最低3〜4文を推奨しています。削るのは定型文で、「いつ使うか」の一文ではありません。
クライアントはすでに長い説明文を黙って切っています。Claude Codeは最初から読み込むツールの説明を先頭4,096文字、ツール検索で読み込むツールは16,384文字までに制限します。日本語の記事でもよく見かける「2,048文字」は、v2.1.296より前のバージョンの値です。
計測は 差分法 で行います。全ツールでトークンを数え、1つ外してもう一度数える。その差がそのツールの実際のコストです。

ツール定義のトークンコストとは
説明文とinputSchema、どちらが重いか（実測）
1つのツールを段階的に書き直す（実測）
サーバーの全ツールを棚卸しする方法
クライアントやAPIは長い定義をどう扱うか
削ってはいけないもの
サーバー全体での削減額（計算例）
チェックリスト
よくあるハマりどころ
NodeFlareならこう解決できる
よくある質問

1. ツール定義のトークンコストとは

ツール定義のトークンコストとは、1つのツールの name・description・inputSchema をモデルが読むために、1リクエストごとに消費される入力トークン数のことです。 MCP仕様（2026-07-28）では、ツールは name、任意の title、description、任意の icons、inputSchema、任意の outputSchema、任意の annotations で定義されます。多くのクライアントは名前・説明文・入力スキーマをモデル向けのツール一覧に変換して毎回送るため、遅延読み込みしない限り、このコストはターンごとに発生します。

Claude APIはツール定義を「JSONSchema形式」でツール用のシステムプロンプトに埋め込みます。料金ページによると、Claude 5.5系で tool_choice: auto の場合、定義とは別に286トークンのツール用システムプロンプトが加わります。

MCPのトークン消費の4つの発生源（システムプロンプト・定義・引数・結果）の全体像は、MCPのトークン消費の全体像と削減方法にまとめています。この記事では、そのうち「定義」だけを掘り下げます。

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

2. 説明文とinputSchema、どちらが重いか（実測）

自動生成されたツールでは、inputSchema が説明文のおよそ2倍のトークンを使っていました。 OpenAPI仕様やPydantic・zodのモデルから生成したツールには、モデルがツールを選んだり呼んだりするのに不要なスキーマのメタ情報がたくさん入っています。

具体的な数字を出すため、課題管理APIのラッパーによくある形の create_issue ツールを用意しました。説明文は1,393文字（使い方の注意、権限、JSONの例、返却フィールドの一覧）、inputSchema は8パラメータで、null許容の anyOf、プロパティごとの title と examples、ネストしたラベルのオブジェクトを含みます。これを圧縮したJSONにしてトークン数を数えました。

計測方法：オフラインで動かせるよう、トークン数はオープンソースの gpt-tokenizer パッケージ（o200k_base トークナイザー）で数えています。Claudeのトークナイザーとは別物で、AnthropicはClaude 4.7以降のモデルでは同じ文章が以前のモデルよりおよそ30%多いトークンになると説明しています。絶対値は目安として、割合を中心に読んでください。Claudeでの正確な数え方は4章で紹介します。

定義の部分	トークン	割合
`inputSchema`	597	64%
`description`	304	32%
`name` + `title`	11	1%
それらを囲むJSONの構造	25	3%
定義全体	937	100%

ここから分かること：

このようなツールでは、説明文だけを直しても効くのは最大で3分の1程度です。今回の検証では、説明文を500文字で切ると937→713トークン（−24%）でした。
パラメータごとのメタ情報が積み上がっています。どのプロパティにも名前を繰り返すだけの title と examples の配列があり、任意項目はすべて anyOf: [{type}, {type: "null"}] に default: null がついていました。
手書きのツールでは逆に、スキーマが小さく説明文が長いことがよくあります。だからこそ、先に計測します（4章）。

3. 1つのツールを段階的に書き直す（実測）

4つの手直しで、パラメータも、モデルが知るべき制約も、「いつ使うか」の案内も残したまま、937トークンが237トークン（−75%）になりました。 各行は前の行の変更を引き継いだ累積の値で、計測方法は2章と同じです。

段階	変更内容	トークン	元との比
0	自動生成のまま（OpenAPI／Pydantic風）	937	100%
1	`$schema`、プロパティごとの `title`、`examples` を削除	838	89.4%
2	null許容の `anyOf` と `default: null` を普通の任意項目に。ラベルは名前の配列に	684	73.0%
3	パラメータ説明で型・任意かどうか・列挙値を繰り返さない	509	54.3%
4	ツール説明を作業目線の4文に書き直し、UI用の `title` を削除	237	25.3%

3.1 モデルが使わないスキーマのメタ情報を外す

$schema は省略できます。MCP仕様には、$schema がなければ inputSchema は2020-12として扱う、と書かれています。プロパティ名を繰り返すだけの title（"owner" に "Owner"）も情報を増やしません。examples は、形式が本当にあいまいな場合を除いてスキーマから外します。例を入れたいなら、Anthropicの input_examples フィールドが正式な方法です。Anthropicはそのコストを、単純な例で約20〜50トークン、複雑なネストしたオブジェクトで約100〜200トークンと公表しています。

3.2 null許容のunionを平らにする

コード生成ツールは「任意」を anyOf: [{"type": "string"}, {"type": "null"}] と default: null で表すことがよくあります。ツール呼び出しでは、そのプロパティを required に入れないだけで同じ意味になります。今回の例では、この段階だけで154トークン減りました（838→684）。あわせて labels を「文字列またはラベルオブジェクト」から名前の配列に変えています。元のAPIが名前を受け付けるからです。この種の単純化は、サーバー側がモデルの送る値を引き続き受け付けられる場合に限って行ってください。

スキーマのルートに anyOf・oneOf・allOf を置くのも避けます。Claude APIはルートでのこれらを受け付けません。Claude Codeはそうしたスキーマを1つのオブジェクトに平らにし、どのパラメータが組になるかを説明する一文を説明文の先頭に足します。そのぶんトークンが増え、自分で書いた平らなスキーマより精度も落ちます。

3.3 パラメータ説明には「スキーマに書けないこと」だけを書く

"type": "string" を見れば文字列だと分かり、required を見れば必須かどうか分かり、enum には値が並んでいます。変更前の説明は「課題のタイトル。このフィールドは必須で、空にはできません。」でした。これは required と minLength の繰り返しなので、説明ごと削除しました。一方で「push権限がなければ無視される」のように、モデルが推測できない制約は残します。

ついでに、Anthropicの命名の助言も取り入れましょう。user ではなく user_id のように、あいまいさのない名前にする、というものです。名前が良ければ説明がいらなくなることもよくあります。

3.4 説明文は「判断に必要なこと」を軸に書き直す

自動生成の説明文は、APIリファレンスそのものでした。レート制限の注意、権限の節、JSONの例、26個の返却フィールドの一覧です。書き直した説明文は、モデルがツールを選ぶのに必要なことだけに答えます。

{
  "name": "create_issue",
  "description": "Open a new issue in a GitHub repository. Use it when the user asks to file a bug, feature request or task; search existing issues first to avoid duplicates. Assignees, labels and milestone are ignored unless the caller has push access. Returns the new issue's number and URL.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "owner": { "type": "string", "description": "Repo owner (user or org)." },
      "repo": { "type": "string", "description": "Repo name, without .git." },
      "title": { "type": "string", "minLength": 1, "maxLength": 256 },
      "body": { "type": "string", "description": "Markdown body." },
      "assignees": { "type": "array", "items": { "type": "string" }, "description": "Logins to assign. Needs push access, else ignored." },
      "milestone": { "type": "integer", "description": "Milestone number. Needs push access, else ignored." },
      "labels": { "type": "array", "items": { "type": "string" }, "description": "Label names. Needs push access, else ignored." },
      "type": { "type": "string", "enum": ["bug", "feature", "task"] }
    },
    "required": ["owner", "repo", "title"]
  }
}

4文・275文字で、Anthropicの「最低3〜4文」の目安にも収まっています。結果をコードで解析するツールなら、出力の形式も短く添えてください。

説明文を日本語で書くか英語で書くか迷う場合は、両方を用意して、実際に使うモデルで4.2の方法で数えて比べるのが確実です。

4. サーバーの全ツールを棚卸しする方法

ツールを「1つ外したら何トークン減るか」の順に並べ、上から直していきます。 無料でオフラインで動く概算と、Claudeのトークナイザーでの正確な計測の2つのスクリプトを紹介します。

4.1 オフラインの概算（説明文とスキーマの内訳）

tools/list の結果を tools.json として保存し、次を実行します。

// audit.mjs — 使い方: node audit.mjs tools.json
import { readFileSync } from "node:fs";
import { encode } from "gpt-tokenizer"; // o200k_base: Claudeのトークナイザーではなく概算

const { tools } = JSON.parse(readFileSync(process.argv[2], "utf8"));
const t = (v) => encode(typeof v === "string" ? v : JSON.stringify(v ?? "")).length;

const rows = tools.map((tool) => ({
  name: tool.name,
  total: t({ name: tool.name, description: tool.description, input_schema: tool.inputSchema }),
  description: t(tool.description),
  schema: t(tool.inputSchema),
  descChars: [...(tool.description ?? "")].length,
}));
rows.sort((a, b) => b.total - a.total);
console.table(rows);
const sum = rows.reduce((s, r) => s + r.total, 0);
const schemaShare = rows.reduce((s, r) => s + r.schema, 0) / sum;
console.log(`tools=${rows.length} total≈${sum} tokens, schema share≈${(schemaShare * 100).toFixed(0)}%`);
console.log(`descriptions over 500 chars: ${rows.filter((r) => r.descChars > 500).length}`);

3章の書き直し前と後のツールでこのスクリプトを実際に動かしています。スキーマの割合が出るので、説明文とスキーマのどちらから手をつけるべきかが分かります。

4.2 Claudeのトークナイザーで正確に数える（差分法）

Anthropicのトークン計測エンドポイントは無料（レート制限あり）で、Messages APIと同じ tools 配列を受け付けます。全ツールで1回数え、次に1つずつ外して数えます。その差が、APIがツールごとに足す分も含めた、そのツールの実際のコストです。

// exact.mjs — ANTHROPIC_API_KEY が必要
import Anthropic from "@anthropic-ai/sdk";
import { readFileSync } from "node:fs";

const client = new Anthropic();
const { tools } = JSON.parse(readFileSync(process.argv[2], "utf8"));
const apiTools = tools.map((t) => ({ name: t.name, description: t.description, input_schema: t.inputSchema }));

const count = async (list) =>
  (await client.messages.countTokens({
    model: "claude-sonnet-5-5",
    messages: [{ role: "user", content: "hi" }],
    ...(list.length ? { tools: list } : {}),
  })).input_tokens;

const full = await count(apiTools);
console.log(`all tools: ${full - (await count([]))} tokens of tool overhead`);
for (const [i, tool] of apiTools.entries()) {
  const without = await count(apiTools.filter((_, j) => j !== i));
  console.log(tool.name, full - without);
}

Anthropicによると、この値は「推定値」で、実際の課金とは「わずかに」ずれることがあります。順位づけには十分な精度です。トークン数はトークナイザーごとに違うので、実際に使うモデルで数えてください。

5. クライアントやAPIは長い定義をどう扱うか

モデルに届く前に、いくつもの層が定義を切ったり拒否したりします。しかも多くは黙って行われます。 どの層も通り抜けられる定義を書きましょう。

層	ルール（2026年10月時点）	出典
MCP仕様	ツール名は1〜128文字、`A-Z a-z 0-9 _ - .` のみにすべき（SHOULD）。`inputSchema` は有効なJSON Schemaオブジェクトでなければならない（MUST）	MCP仕様 2026-07-28
Claude Code（最初から読み込むツール、サーバーの説明）	説明文を4,096文字で切る	Claude Code MCPドキュメント
Claude Code（ツール検索で読み込むツール）	16,384文字で切る。検索の照合は短い方の上限内だけを読む	Claude Code MCPドキュメント
Claude Code（v2.1.296より前）	2,048文字	Claude Code MCPドキュメント
Claude Code	`CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH` で両方の上限を置き換え	Claude Code 環境変数
Claude Code／Claude API	トップレベルのプロパティ名は1〜64文字。スキーマはdraft 2020-12に準拠。フルネームが128文字を超えるツールは除外	Claude Code MCPドキュメント
Claude API	スキーマのルートに `anyOf`・`oneOf`・`allOf` は不可（Claude Codeは平らにして送る）	Claude Code MCPドキュメント

ここから実務上のルールが2つ出てきます。

判断材料を先頭に書く。最初の一文で「何をするツールで、いつ使うか」を書きます。切られても残るのはそこで、ツール検索が照合するのもそこです。
サーバーの説明（instructions）を意識して書く。ツール検索が有効なClaude Codeは、起動時にツール名とサーバーの説明だけを読み込みます。どんな種類の作業を扱うサーバーで、いつツールを検索すべきかを書くよう、ドキュメントでも勧められています。

6. 削ってはいけないもの

軽量化で削るのは定型文で、判断に必要な情報ではありません。 Anthropicのツール定義ガイドは「非常に詳しい説明を書くこと。これがツール性能を左右する圧倒的に重要な要素」とはっきり書いています。エンジニアリングブログでも、説明文の小さな改善が劇的な効果を生むことがあると述べています。

残すもの	削る・別の場所へ移すもの
何をするツールで、いつ使うか（最初の一文）	APIリファレンスの文章、レート制限の説明、変更履歴
使うべきでない場面、代わりに使うツール	返却フィールドの全一覧
モデルが推測できない制約（権限、副作用、取り消せない操作）	型・任意かどうか・列挙値の繰り返し
結果をコードで解析する場合の出力形式	説明文の中のJSONの例（必要なら `input_examples` へ）
誤った呼び出しを防ぐ `enum`・`required`・`minimum`/`maximum`	`$schema`、重複する `title`、`examples` 配列、null許容のunion

言い回しの修正より大きく効く、構造の変更が2つあります。

関連するツールをまとめる。Anthropicは create_pr・review_pr・merge_pr のような操作を、action パラメータを持つ1つのツールにまとめることを推奨しています。owner や repo のような共通パラメータの定義が3回から1回になります。
名前に名前空間をつける。github_list_prs のような接頭辞でツール選択があいまいでなくなります。Anthropicは、これはツール検索を使う場合に特に重要だとしています。

7. サーバー全体での削減額（計算例）

私の計算では、3章の書き直しを30ツールのサーバーに当てはめると、ツールを最初から読み込む場合で1リクエストあたり約21,000入力トークンが減ります。

1ツールあたりの削減：937 − 237 = 700トークン（o200kでの概算）。1リクエストあたり：700 × 30 = 21,000トークン。
Claude Sonnet 5.5（入力100万トークンあたり$2）：21,000 ÷ 1,000,000 × $2 = 1リクエストあたり$0.042、1,000リクエストで$42。
Claude Opus 5.5（100万トークンあたり$4）：1リクエストあたり$0.084。
プロンプトキャッシュが効けば、Sonnet 5.5のキャッシュ読み取りは100万トークンあたり$0.10なので、21,000 ÷ 1,000,000 × $0.10 = 1リクエストあたり$0.0021。安くはなりますが、21,000トークンがコンテキストを占めることは変わりません。20万トークンのコンテキストなら10.5%です。
ツール検索を使う場合、定義のトークンは読み込まれたときにだけかかりますが、1回の読み込みあたりのコストは同じです。軽い定義はここでも効きます。また、Claude Codeのツール検索が照合するのは先頭4,096文字だけです。

料金はAnthropicの料金ページ（2026年10月時点）によります。実際の数値はツールの中身とClaudeのトークナイザーで変わるので、4.2の方法で数え直してください。

8. チェックリスト

[ ] 各ツールの差分コストを countTokens で計測した（全ツールと1つ外した場合の比較）
[ ] 説明文とスキーマのどちらが重いかを把握した（棚卸しのスキーマ割合）
[ ] inputSchema に、不要な $schema・重複する title・examples がない
[ ] 任意項目は required に入れないだけにしており、null許容の anyOf にしていない
[ ] スキーマのルートに anyOf・oneOf・allOf がない
[ ] パラメータ説明にはスキーマで表せないことだけを書いた
[ ] ツール説明は3〜4文で「何を・いつ」が先頭にあり、できれば500文字程度に収めた
[ ] 関連する操作をまとめ、ツール名に名前空間をつけた
[ ] サーバーの説明に「いつこのサーバーのツールを検索すべきか」を書いた
[ ] MCP仕様の推奨どおり、ツールの並び順が毎回同じ
[ ] 軽量化のあと実際の作業をいくつか流し、ツール選択が悪化していないことを確認した

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

症状	原因	対処
説明文を短くしたのにトークンがほとんど減らない	スキーマの方が重い	棚卸しを実行し、`inputSchema` に3章の段階1〜3を適用する
軽量化後にモデルが違うツールを選ぶ	「いつ使うか」「いつ使わないか」の文まで削った	その文を戻し、代わりに定型文を削る
あるクライアントでは動くのにClaude Codeでツールが出てこない	ルートのcombinator、不正なスキーマ、長いプロパティ名、128文字を超えるフルネーム	平らなオブジェクトのスキーマ、2020-12準拠、短い名前にする
長い説明文の最後に書いた重要なルールが無視される	4,096文字（古いClaude Codeでは2,048文字）で切られている	重要な内容を最初の数文に移す
ツール検索で自分のツールが見つからない	検索されそうな語が説明文の奥にある	主な名詞・動詞を先頭近くに置き、サーバーの説明も書く
キャッシュヒット率が下がった	説明文にタイムスタンプが入っている、またはリクエストごとに変わる	定義をバイト単位で固定し、並び順も固定する

ツールの説明文は攻撃の入口にもなります。説明文の中身はそのまま指示としてモデルに届くからです。他者のサーバーを使う場合は、MCPのツールポイズニング対策もあわせて確認してください。

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

NodeFlareはMCPサーバーをホスティングし、プロキシでサーバーごとのトークン設定を提供しています。いずれもサーバーのコード変更は不要なので、定義を書き換えられない他者のサーバーでも使えます。この記事で挙げた課題ごとに対応を整理します。

課題：長い説明文をすべて書き直す余裕がない。自分のサーバーではないので書き換えられない（2章・5章） tool_schema_slim をオンにします。500文字を超えるツールの説明文が（UTF-8を壊さずに）切り詰められ、名前と入力スキーマはそのまま残ります。2章の検証では、これだけで自動生成のツールが937→713トークンになりました。スキーマには手が入らないので、自分で管理するサーバーでは3章のスキーマの手直しと組み合わせてください。

課題：定義を軽くしても、ツールが多いと合計が積み上がる（7章） tool_search_mode をオンにします。tools/list が search_tools(query) と call_tool(name, args) の2つのメタツールにまとめられ、モデルは検索したツールだけを読み込みます。GEMINI_API_KEY を設定すると検索が意味検索（埋め込み）になり、設定しない場合はキーワード検索になります。自前のツール検索を持たないクライアントでも使えます。

課題：呼び出し元が使えないツールまで一覧に出ている tool_list_filter_by_scope をオンにします。tools/list が、呼び出し元の資格情報で実際に呼べるツールだけに絞られます（スキーマは同じ）。一覧に出るツールが減れば、毎回送られる定義も減ります。

課題：定義は費用の一部にすぎず、複数ステップの作業ではツールの結果もモデルを通る Code Execution（tool_code_mode）をオンにします。サーバーは run_code と search_tools を公開し、モデルは tools.* を呼ぶJavaScriptを書きます。コードはサンドボックスで実行され、複数のツール呼び出しが何往復ものやり取りではなく1回の実行にまとまります。既定値はタイムアウト600秒、1回の実行あたりツール呼び出し50回まで、サンドボックスのプロセスごとにV8ヒープ128MBです。モデルは最初に全定義を読むのではなく、run_code と search_tools を通じて作業します。どんな場合にコードモードが得になるかは、MCPのコード実行の損益分岐で解説しています。

NodeFlareは決まった削減率を公表していません。導入前後で、4章の方法で自分のサーバーを計測してください。

最小の始め方：

nodeflare.techにサインインし、MCPサーバーのGitHubリポジトリを選びます。ランタイムや起動コマンドは自動で入力され、Dockerfileやコードの変更はいりません。
デプロイしたら、サーバー設定で tool_schema_slim と tool_code_mode（または tool_search_mode）をオンにします。
サーバーのURLとAPIキーをMCPクライアントに追加します。

MCPサーバー1つまで無料で試せます（Freeプラン：サーバー1つ、月30 GB-時のコンピュート）。→ nodeflare.techで始める

11. よくある質問

MCPのツール定義は何トークン使う？

説明文とスキーマ次第です。今回の計測では、自動生成した8パラメータの create_issue ツールが937トークン（o200kでの概算）、書き直した版が237トークンでした。Anthropicが公表している実在のサーバーの数値は、約2K（Splunk、2ツール）から約26K（GitHub、35ツール）まで幅があります。

MCPツールの説明文は入力トークンとして課金される？

はい。Anthropicはツール利用時の入力トークンを、tools パラメータも含めてすべて課金します。Claude 5.5系では tool_choice: auto の場合、さらに286トークンのツール用システムプロンプトが加わります。

inputSchemaもMCPのトークン消費に含まれる？

含まれます。しかも重い方であることが多いです。今回の検証ではスキーマがツール全体の64%でした。プロパティの title、examples、null許容の anyOf がよくある原因です。

MCPツールの説明文はどのくらいの長さがいい？

Anthropicは最低3〜4文、複雑なツールならそれ以上を推奨しています。何をするツールで、いつ使うかを最初に書きます。多くのツールでは300〜500文字程度でそれが書け、5章のどのクライアントの上限にもかかりません。

Claude CodeはMCPツールの説明文を切り詰める？

はい。最初から読み込むツールとサーバーの説明は先頭4,096文字、ツール検索で読み込むツールは16,384文字までです。v2.1.296より前は2,048文字でした。CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH で両方の上限を変更できます。

inputSchemaから$schemaは消していい？

たいていは消して構いません。MCP仕様では、$schema がなければ inputSchema はJSON Schema 2020-12として扱われます。draft-07など別の方言をあえて使う場合だけ残してください。

input_examplesもトークンを使う？

使います。Anthropicによると、単純な例で約20〜50トークン、複雑なネストしたオブジェクトで約100〜200トークンです。形式にうるさい入力やネストした入力に絞って使い、すべてのツールにはつけないでください。

outputSchemaはモデルのトークンを使う？

クライアント次第です。Claude APIのツール形式が受け取るのは name・description・input_schema なので、outputSchema がモデルに届くのはクライアントが追加した場合だけです。クライアントが何を送っているかを確認し、差分法で計測してください。

説明文を短くするとツール選択が悪くなる？

削る場所を間違えると悪くなります。リファレンス的な文章、型の繰り返し、例は削り、「何を・いつ・いつ使わないか・制約」は残します。軽量化のあとに実際の作業をいくつか流し、ツールの選び方を比べてください。

ここでの「MCP Token」はAPIトークンのこと？

違います。この記事はツール定義が消費するLLMのトークンの話です。MCPサーバーに使うAPIキーやOAuthのアクセストークンはセキュリティの話題です。

まとめ

ツール定義によるMCPのトークン消費は、リクエストのたびに払う固定費で、説明文よりも inputSchema が原因になっていることがよくあります。ツールごとの差分コストを計測し、スキーマのメタ情報とnull許容のunionを外し、パラメータ説明にはスキーマで表せないことだけを書き、ツール説明を判断に必要な3〜4文に書き直します。今回の実測例では、これで1つのツールが75%軽くなりました。「いつ使うか」の案内は残して先頭に置き、クライアントに切られても残るようにします。ツールが多い場合は、軽い定義にツール検索やコード実行を組み合わせてください。