你接了五個 MCP server——GitHub、Slack、Sentry、Grafana、Splunk——打開 Claude Code，一個字都還沒輸入，context 已經被吃掉三分之一。

先別急著問怎麼修。先搞清楚一件更基本的事：那三分之一，到底是被什麼東西佔走的？把這個搞懂，後面的解法你會覺得理所當然，甚至能自己想到。

那些 token 是被「說明書」吃掉的

當你給 Claude 接上一個工具，Claude 並不是「知道有這個工具存在」就好。它必須拿到那個工具的完整使用說明書，才能正確呼叫它。這份說明書包含三樣東西：工具的名字、一段描述它能幹嘛的文字、還有最佔空間的——完整的參數結構（JSON schema），每個參數叫什麼、是什麼型別、必填還是選填、有什麼限制，全部都要寫清楚。

一個工具的說明書，可能就是幾百到上千個 token。而一個典型的多 server 設定，大概 58 個工具，全部說明書加起來大約 55,000 token。有人實測接到一定數量後，光是這些定義就吃掉 66,000 token。對一個 200K context 的模型來說，你還沒開始工作，工作記憶就先被一疊「待命中、但這次根本用不到」的說明書佔走了三分之一。

這裡有個關鍵要看清楚：傳統的做法是所有工具的說明書，在對話一開始就全部攤開塞進 context，不管你這次的任務用不用得到。你今天只是想叫它看一下 GitHub 的 PR，但 Slack、Grafana、Splunk 那幾十份說明書照樣佔著位置陪你坐到散場。

它害你的，不只是記憶體

如果問題只是「吃掉一些 token」，那還算單純，頂多就是貴一點、context 短一點。但它其實是雙重損失，而第二重比第一重更隱蔽。

想像你要修一個水龍頭，結果有人把整間五金行的工具——電鑽、砂輪機、各種尺寸的扳手板手、焊槍——全部倒在你的工作桌上。你需要的只是一支六分扳手。現在桌上攤了五十樣東西，你光是「在這堆裡認出那支扳手」就要多花力氣，而且很容易順手抓錯一支。

模型選工具就是這樣。當 context 裡同時攤著 50 多個工具的說明書，模型挑對工具的準確率會下降——選項太多本身就是雜訊。所以這 55K token 不只是「佔空間」，它還主動讓 Claude 變笨。你付了雙倍的代價：又貴、又選得更差。

Tool Search：先給索引，要用再抽

現在來看解法。一旦你想通了問題是「不該把整間五金行都倒上桌」，解法幾乎是自己浮出來的——你需要的不是把工具搬上桌，是一張館藏索引。

這就是 Tool Search 在做的事。它的機制可以拆成四步：

第一步，你在提供工具定義時，把那些不必馬上載入的工具標上 defer_loading: true（在 Claude Code 裡，這對 MCP 工具是預設行為）。被標記的工具，它們的完整說明書不會一開始就進 context。

第二步，Claude 對話開始時，眼前只看到兩樣東西：一個「搜尋工具的工具」（tool search tool 本身），加上少數沒被 defer 的常用工具。它知道「外面還有很多工具」，但手上只有一張能去查的索引卡，沒有那五十份說明書。

第三步，當任務真的需要某個工具時，Claude 用那個搜尋工具去查——比方它要操作 GitHub，就搜尋跟 GitHub 相關的工具。API 回傳 3 到 5 個最相關的 tool_reference，這些 reference 會被自動展開成完整的工具定義。

第四步，Claude 從這幾個剛剛抓進來的工具裡挑一個、填好參數、呼叫。任務需要哪本書，才去架上把哪本抽下來，用完它就在那，不需要的那四十幾本從頭到尾沒上過你的桌子。

效果有多大？傳統做法 50+ 工具吃掉約 77K token，換成 Tool Search 之後降到約 8.7K，省下將近 85%，保住了 95% 的 context。而那個搜尋工具本身，只佔大約 500 token——用 500 token 的索引，換掉 77K 的說明書堆，這筆帳怎麼算都划算。

機制細節參考 Claude API 官方文件 — Tool search tool。

在 Claude Code 裡，它已經幫你開好了

講了半天原理，實際操作其實很無感——這正是它做得好的地方。

在 Claude Code 2.1.x，Tool Search 已經是預設開啟的：它會自動 defer 掉所有 MCP 工具的定義，等到某個任務需要時才去發現、載入。控制它的環境變數是 ENABLE_TOOL_SEARCH。也就是說，如果你用的是近期版本、又接了一堆 MCP server，你很可能已經在享受這個機制的好處，只是沒察覺。

我自己這個工作階段就是活生生的例子：啟動時我看到的是一份「延遲工具」清單——只有工具名字，沒有任何參數說明。要等我真的需要查 Notion、查某個 API 的時候，才去把那份完整的 schema 抓進來。整間五金行的工具確實都在，但它們乖乖待在架上，沒有一開始就倒到我桌上。

它還沒解乾淨的部分

工具介紹最該老實的地方，就是講清楚它哪裡還不行。Tool Search 不是萬靈丹，社群已經回報了幾個邊角：

有人發現 HTTP / Streamable HTTP 類型的 MCP 工具沒有被正確 defer，結果每個 session 還是會 upfront 載入 120K token（issue #40314）——也就是說，這個機制目前對 stdio 類型的 server 最有效，HTTP transport 還有漏網的情況。另外也有人回報，當工具沒有超過 context 的某個比例門檻時，Tool Search 不會自動啟用（issue #18298），這在工具不多不少、剛好卡在門檻附近時會有點尷尬。

所以實務上，如果你接的 MCP 很多、又發現 context 莫名其妙被吃掉，值得去確認一下 ENABLE_TOOL_SEARCH 的狀態、以及你的 server 是哪種 transport，而不是假設「反正新版會自動處理」。

同一招，會在很多地方再遇到

退一步看，Tool Search 真正的價值不在「省了 85% token」這個數字，而在它示範了一個你會一再用到的模式：當資源有限時，先給索引、不給全文，需要時才載入。

這個模式有個名字叫 progressive disclosure（漸進揭露）。它的對立面，是「把所有可能用到的東西一次全攤開」——而那幾乎永遠是錯的，因為 context 是有物理上限的稀缺資源，你攤開的每樣東西都在跟「你真正在想的事」搶空間。

看懂這一點，你會發現它到處都是。你的 CLAUDE.md 不該寫成 3000 行的百科全書，而該是一張地圖，指向需要時才去讀的細節；一個設計良好的 skill，是先給一句「我能幹嘛」，要用才展開完整指引；連 AI 的長期記憶，本質上也是同一個問題——不可能把所有記憶都塞進當下這次對話，只能先給索引、按需召回。Tool Search 只是這個模式在「工具」這個維度上的一次具體實作。

下次你看到任何「東西多到塞不下」的場景，先別急著買更大的桌子。先問一句：我是不是該給它一張索引，而不是把整座圖書館都搬上來？這個提問，比這篇講的任何一個指令都值錢。