Claude Code に MCP サーバーを増やしすぎると、便利になったはずなのに、早く compact される、tool の選択がぶれる、ログや issue を一度読ませただけで会話が重くなる、という状態になりがちです。原因は単純な「サーバー数」だけではありません。ツール定義、ツール結果、長い会話の残り、似たツールが多い選択面という四つのコストが、同じ context window を使っています。
2026 年 5 月 23 日時点で、Claude Code は MCP の設定、Tool Search、MCP tool output が 10,000 tokens を超えた時の警告を文書化しています。Tool Search は、対応している経路では tool definition の前置きロードを抑えられます。ただし、無関係なサーバー、大きすぎる戻り値、古い修正履歴、proxy や互換 provider の違いまで無料にする機能ではありません。
最初に作るべきなのは、サーバー一覧ではなくコンテキスト予算表です。
| コスト | 画面で起きること | 最初の直し方 |
|---|---|---|
| ツール定義 | 呼び出し前から名前、説明、schema が多く見えている。 | Tool Search を確認し、今の作業に不要な server は後回しにする。 |
| ツール結果 | ログ、取得結果、DB 行を返した後に急に重くなる。 | summary、filter、limit、pagination、cursor、handle を使う。 |
| 会話の残り | 失敗案、古い計画、やり直しが残り、新旧の判断が混ざる。 | 現在の判断を短くまとめ、必要なら新しい thread に移る。 |
| 選択面 | 複数の server が似た read/search/list を出している。 | workflow ごとに owner を一つにし、広すぎる custom server は分ける。 |
すぐやる作業は小さいです。Claude Code で /mcp を実行し、今回の作業に本当に必要な server を列挙します。次に keep、defer、disable、split、redesign のどれかを付けます。足りないのが手順なら skill、外部データや操作面なら MCP です。MCP を残す場合も、戻り値は小さくする前提で使います。
まずコンテキスト予算に分解する
MCP サーバーは、設定ファイルの名前だけではありません。MCP tool には name、description、input schema、場合によって output schema と返却 content があります。Claude Code がどのタイミングでそれをモデルに見せるかは読み込み経路によりますが、どの経路でも tool definition は設計上のコストです。
さらに重いのは tool result です。たとえば server が一つだけでも、データベースを 8,000 行返す、Playwright の snapshot を丸ごと返す、ログを全部返す、GitHub issue を制限なしで返す、という設計なら、context window はすぐ圧迫されます。逆に、責務がはっきりした三つの server が、それぞれ小さな summary だけを返すなら、実務上は問題にならないこともあります。
診断は、痛みが起きる場所で分けます。tool call 前から遅いなら、tool definitions、長すぎる descriptions、似た名前の tools、常時 active な server を見ます。tool call 後に悪化するなら、戻り値の大きさと形です。修正を何度も繰り返した後に混乱するなら、MCP ではなく会話の残りが主因かもしれません。
| 症状 | 疑うコスト | 見る場所 |
|---|---|---|
| 外部呼び出し前から遅い | definitions または decision surface | /mcp、server list、tool names、descriptions |
| 一回呼ぶと急に乱れる | result load | logs、tables、files、raw rows、trace |
| 長い修正後に前提が戻る | session residue | old errors、old plans、abandoned branches |
| tool を選び間違える | decision surface | 同じ役割の read/search/list が複数あるか |
この分け方をすると、全部の MCP を消す必要はありません。必要なのは、今の作業で owner を持つ server だけを active にすることと、戻り値を小さくすることです。MCP は外部能力を与えるためのものですが、主会話に常時置く権利は別問題です。
Tool Search は助けるが、戻り値は残る
Tool Search は、古い MCP 設計論を少し更新します。対応している Claude Code の経路では、tool definitions を必要になるまで遅らせられるため、最初からすべての schema と descriptions が重く乗る状態を避けやすくなります。
ただし、Tool Search は tool result を圧縮しません。Claude が実際に tool を呼んだ後、戻ってきた表、ログ、ファイル、HTML、JSON、DB rows は会話の一部になります。context window は現在の作業記憶なので、そこに入った内容は他の推論スペースと競合します。
境界は三つです。
| 境界 | Tool Search ができること | 解決しないこと |
|---|---|---|
| 前置き定義 | 対応経路で discovery と definition load を遅らせる。 | tool 名が曖昧、説明が長い、owner が重複している。 |
| tool results | 基本的に何もしない。 | 大きな logs、tables、trace、files、raw API payload。 |
| 会話履歴 | 基本的に何もしない。 | 長い thread、失敗した修正、古い判断、重複出力。 |
ANTHROPIC_BASE_URL、proxy、互換 gateway、custom model path を使う場合は、自分の環境で確認してください。Tool Search が動いていても、large output の問題は残ります。実務では、まず一つの real workflow を流し、悪化するタイミングを見ます。前なら server selection、後なら output compression です。
Keep、defer、disable、split、redesign
MCP の整理は、数を減らす競争ではありません。active list を説明できる状態にする作業です。各 server について「今回の作業では、この server が ____ を担当する」と言えなければ、今は active にしない方がよいです。
| 判断 | 使う場面 | 例 |
|---|---|---|
| Keep | 今の workflow を持っており、local file、memory、skill では代替できない。 | PR review 中の GitHub MCP、framework 移行中の docs MCP。 |
| Defer | 後で必要だが、今の段階では不要。 | UI 修正が終わるまで browser QA を待たせる。 |
| Disable | 今の作業に関係ない、または別 server と役割が重複する。 | 同じ library doc を読む server が二つある。 |
| Split | 一つの custom server が unrelated actions を抱えすぎている。 | issue search と deployment write を分ける。 |
| Redesign | server は必要だが、tool が広すぎて戻り値が大きい。 | dump_database を search_errors(service, time_range, limit) に変える。 |
/mcp は現在の Claude Code セッションを見るのに向いています。設定全体を確認するなら claude mcp list、claude mcp get、claude mcp remove を使います。ただし目的は、設定を空にすることではありません。現在の作業で、Claude が迷わず選べる active owners だけにすることです。
まだ最初の MCP を選んでいる段階なら、Best Claude Code MCP Servers のような導入ガイドが先です。ここで扱うのは、すでに増えすぎた setup を、作業単位で使える大きさに戻す段階です。
tool output は会話に入る前に小さくする
Tool Search を確認した後、本当に効くのは output compression です。巨大な tool result は、server 数より強く context window を圧迫します。ログを全部返す、DB 行を制限なく返す、issue を全件返す、snapshot を丸ごと返す、これらは便利ではなく負債です。
Claude Code の 10,000 tokens 警告や MAX_MCP_OUTPUT_TOKENS は最後の guardrail です。目標は、その上限ぎりぎりまで詰めることではありません。次の判断に必要な最小情報だけを返すことです。
| ルール | 悪い戻り値 | よい戻り値 |
|---|---|---|
| summary first | ログ全文 | 異常種別、件数、代表 3 行 |
| filter at source | 全 rows | service、time range、status、owner で絞った rows |
| paginate | 巨大な一回応答 | initial batch と next_cursor |
| default cap | 無制限 | limit: 20、必要時だけ拡大 |
| return handles | ファイル全文や dataset 全体 | file path、object id、job id、stored result |
| preview before raw | raw payload 直返し | summary を先に返し、raw は別パラメータ |
ユーザー側の質問も重要です。「DB を読んで」ではなく「過去 24 時間の top 20 errors を service ごとにまとめ、count と sample trace を一つずつ」と聞きます。「logs を見て」ではなく「deploy failed 以降の error 行だけ、health check は除外」と指定します。問いが小さければ、tool の戻り値も小さく設計できます。
コンパクトな MCP server を設計する
自分で MCP server を作っているなら、最も効くのは server の on/off ではなく tool design です。Claude に見せる tool は少なく、名前は具体的に、description は短く、default は summary、detail は明示要求にします。
確認項目は次の通りです。
- 一つの tool は一つの仕事だけを持つ。issues、logs、metrics、files、deployments を混ぜない。
- 実装名ではなく結果名で呼ぶ。query_system より search_recent_errors。
- description は選択のために書く。backend 全体の説明にしない。
- 似た tool を増やす代わりに mode: summary/detail/export を使う。
- summary を default にし、raw output は explicit にする。
- 大量データには filter、limit、pagination、cursor を必ず用意する。
- 大きすぎる payload は path、id、handle で返す。
- read-only exploration と write actions を分け、危険な操作は名前でわかるようにする。
悪い例は get_everything_from_database() です。rows、logs、traces、metadata を全部返し、Claude に「全部読んでから判断して」と強制します。よい例は search_errors(service, time_range, limit) です。summary、top rows、next_cursor を返し、次に何を深掘りするか選べます。
重い探索を main thread から外す
解決策が「MCP を減らす」だけとは限りません。「重い MCP 探索を main thread に置かない」こともあります。Claude Code の subagents は、ログ調査、候補整理、仮説検証を別の狭い context で行い、main thread に findings だけ返す用途に向いています。
ただし subagent は自動的な圧縮境界ではありません。tool inheritance を広くすると、main thread と同じ量の tools を持ってしまい、同じ問題を別の場所で起こします。探索用 agent には必要な tools だけを与え、raw dump ではなく findings、counts、paths、risks、next actions を返すようにします。
Skill はさらに別の層です。足りないものが repeatable method、checklist、reference bundle、script sequence なら skill を使います。足りないものが外部アクセスや action surface なら MCP を使います。両方必要なら、MCP は reach、skill は operating method として分けます。永続ルールは長い transcript に頼らず、memory に置きます。
20 分の MCP クリーンアップ
Claude Code が早く compact される、tool を選び間違える、ログを読んだ後に混乱する、という時は短い cleanup pass を行います。
- /mcp を実行し、active server を書き出す。
- それぞれに keep、defer、disable、split、redesign を付ける。
- current workflow owner がない server は外す。
- 同じ小さなタスクを再実行し、痛みが tool call 前か後かを見る。
- 前なら definitions、names、descriptions、Tool Search support を見る。
- 後なら output size、summary、filter、limit、cursor、handle を見る。
- 多くの retry 後なら current decision をまとめ、新しい thread に移る。
- 方法が足りないだけなら、server を増やさず skill にする。
見るべき数字は configured servers の総数ではありません。現在の作業で active な選択肢の数と、一回の tool call が conversation に持ち込むデータ量です。最小で十分な MCP setup は地味ですが、Claude が推論しやすい setup です。
よくある質問
Tool Search で MCP のコンテキスト圧迫はなくなりますか？
なくなりません。対応経路では upfront tool definitions を減らせますが、tool results、古い会話、重複 server、広すぎる custom tools は別に直す必要があります。
Claude Code では MCP server をいくつ有効にすべきですか？
固定の数字はありません。current workflow を持つ server だけを有効にします。一つの database MCP が巨大な dump を返せば、少数でも重くなります。
MCP tool output が大きい時はどうしますか？
source 側で小さくします。summary、filter、pagination、limit、cursor、file path、object id、handle を使います。raw data は default ではなく明示要求にします。
skill と MCP はどう選びますか？
手順や判断方法が足りないなら skill、外部データや操作面が必要なら MCP です。両方必要な workflow では、MCP がアクセスを担当し、skill が作業方法を担当します。
コンパクトな MCP server の条件は何ですか？
少ない tools、明確な owner、短い description、bounded output、filters、limits、cursors、summary first、read/write separation です。全データを一度に返す tool は避けます。
全部の MCP を止めるのが安全ですか？
診断としては有効ですが、長期解ではありません。必要なアクセスは残し、不要な server は defer か disable にし、大きすぎる戻り値を出す tools を redesign します。
Claude Code の MCP コンテキスト圧迫は、統合を減らすだけではなく、作業記憶を予算として扱うと直しやすくなります。今の workflow に owner を持つ server だけを残し、大きな結果は会話に入る前に圧縮し、方法は skill に、重い探索は狭い context に移します。Claude が迷わない MCP setup は、たいてい最小で十分な setup です。