MCP 連太多會很燒 token 嗎？Tool Search 按需載入機制解析

先給結論：連很多 MCP 確實會吃掉 token，而且是在你問任何問題之前就先吃掉，一套 5 到 10 個 MCP server 的組合，光是把每個工具的「使用說明書」攤進 AI 的記憶體，就可能燒掉 10 萬到 20 萬個 token。但你聽說的那個「有需要才載入」的機制也是真的，它叫 Tool Search，目前已經能把這筆開銷砍掉大約 85%。這篇文章用最白話的方式，把這兩件事一次講清楚。

這個問題其實是我們每天在處理的。我們公司內部跑著 20 多個 AI 流程，每一個都串了不少外部工具，查資料庫、自動發信、讀文件、接第三方系統。工具一多，我們很快就撞到同一道牆：AI 的記憶體被工具說明塞滿，回應變慢、變貴，有時候還挑錯工具。後來才搞懂，這背後是 MCP 這個協定的設計取捨，以及一個正在快速普及的解法。

如果你對 MCP 這個詞還很陌生，它的全名是 Model Context Protocol，可以想成「AI 助理跟各種工具、資料之間的萬用插座」。我們在 這篇 MCP 是什麼的完整解析 已經把它的定義、跟傳統 API 差在哪講得很細，這篇就不重複；這裡專心回答一個更實際的問題：工具接多了到底會發生什麼事、又該怎麼控管成本。

連一個 MCP，AI 還沒開口就先燒掉幾萬 token

要理解這件事，得先知道 AI 助理的記憶體（也就是常聽到的 context window）是有上限的。目前主流模型大約是 20 萬個 token，你可以把它想成一張固定大小的桌子，AI 要工作的所有東西，包括你的問題、它的思考、對話歷史，全部都得攤在這張桌子上。

問題來了：每接上一個 MCP server，這個 server 底下所有工具的完整定義（工具名稱、用途說明、每個參數怎麼填）都會被搬上桌，而且是每一次對話都重新搬一遍不管你這次用不用得到它。GitHub 官方的 MCP server 光是工具定義就佔掉約 55,000 個 token，再接上 Jira 又多了大約 17,000 個。Anthropic 自己也揭露過，他們內部某套配置在優化前，工具定義就吃掉了 134,000 個 token，這代表 AI 還沒讀到你的第一句話，桌子就已經被佔掉三分之二。

把幾個常見的 server 疊起來，數字會很驚人。一份 The New Stack 的整理 指出，典型的 5 到 10 個 MCP server 組合，在使用者輸入任何字之前就燒掉 10 萬到 20 萬個 token，幾乎把整張桌子佔滿。下面這張表讓你對「工具的重量」有具體概念：

MCP 來源 / 情境	工具定義佔用 token	白話換算
GitHub 官方 MCP（約 93 個工具）	約 55,000	相當於一本中篇小說
再加上 Jira	再加約 17,000	桌子又少一角
Anthropic 內部某配置（優化前）	約 134,000	還沒對話就用掉約 2/3 桌面
典型 5–10 個 server 疊加	100,000–200,000	幾乎佔滿整張 20 萬桌面

換句話說，「加很多 MCP 會很燒 token」這個直覺，方向完全正確。而且它燒的是最寶貴的那種 token：固定開銷，每一輪對話都要付一次。

為什麼會這樣？工具的「使用說明書」每次都攤在桌上

MCP 的原始設計很單純：為了讓 AI 知道自己有哪些工具可用，它要求把所有 server、所有工具的資訊，全部先告訴模型。這個設計在工具只有三五個的時候沒問題，但當生態系爆炸成長後，就變成沉重的負擔。

打個比方。這就像你每次請一位師傅來修東西，他都堅持先把整間工具房裡的每一支工具，連同每一本使用手冊，全部搬到你家客廳攤開，即使這次只是要換一顆螺絲。工具房裡的東西越多，他搬進搬出的時間就越長，你家客廳能站人的空間就越少。AI 的「桌子被工具說明塞滿」，就是這個畫面。

多個 MCP 工具串接形成的網路節點，象徵工具數量膨脹

工程圈把這個現象叫做 schema bloat（工具定義膨脹）。它的代價不只是佔空間，有人實測過，透過 MCP 做一次簡單的「列出資料夾內容」，竟然比直接寫一小段程式來做同一件事多花了 12 倍的 token。工具的「使用說明」本身，往往比你真正要它做的事還要重。

這也解釋了一個常見的困惑：為什麼有些人裝了一堆強大的 AI 工具，AI 反而變得又慢又笨？因為桌子就那麼大，說明書佔得越多，留給「實際思考」的空間就越少。

對企業的真實代價：更慢、更貴，還可能更笨

對中小企業老闆來說，token 是抽象的，但它換算成的三件事很具體。第一是變慢：模型要先讀完所有工具說明才能開始回答，工具越多，每一次回應的延遲就越長。第二是變貴：商用 AI 多半按 token 計費，那些每輪重複載入、卻多半用不到的工具定義，等於是你每問一句話就重複付一次的「停車費」。

第三件事最容易被忽略，也最傷：AI 會變笨。工具選項一多，模型反而容易挑錯工具或漏掉該用的工具。Anthropic 公布的評測就很說明問題，在工具很多的情境下，Opus 4 挑對工具的準確率原本只有 49%，導入按需載入機制後才拉到 74%；Opus 4.5 也從 79.5% 提升到 88.1%。換句話說，把工具全部攤在桌上，不只浪費錢，還真的會讓 AI 表現變差。

成本差距有時誇張到不合直覺。有一份效能測試比較了用指令列工具（CLI）跟用 MCP 做同一件事，發現 MCP 每個操作要多花 4 到 32 倍的 token；其中「偵測一個程式庫用什麼語言」這件小事，走 CLI 只要 1,365 個 token，走 MCP 卻飆到 44,026 個。這種落差大到讓部分廠商重新評估，Perplexity 的技術長在 2026 年 3 月就公開表示，他們內部正式系統決定不再用 MCP，改走自家的直接整合。

代價	發生什麼事	老闆實際感受
更慢	模型要先讀完所有工具說明才能動工	客服機器人、內部助理回應變鈍
更貴	每輪重複載入用不到的工具定義都在計費	API 帳單莫名其妙地高
更笨	工具選項過多，模型挑錯或漏用	明明裝了工具，AI 卻不會用或用錯

這其實呼應了一個我們一直在講的觀念：工具不是越多越好。我們在 企業 AI 工具整合策略：為什麼少即是多 這篇談過「AI 腦過熱」的問題，MCP 的 token 膨脹，正是這個道理在技術底層的具體版本。

AI 怎麼做到「有需要才載入」？Tool Search 白話拆解

好消息是，這個問題現在有了相當成熟的解法。Anthropic 在 2026 年 1 月 14 日正式推出了一個叫 Tool Search（工具搜尋） 的機制，而且對多數使用者來說是預設開啟、不需要自己設定的。它徹底改變了「工具怎麼進到 AI 記憶體」這件事。

原理用一句話講就懂：平常桌上只放一本工具目錄，不放說明書；AI 真的要用某支工具時，才去把那一本說明書翻出來。技術上，AI 平常只看得到每個工具的名字跟一句簡介，完整的參數定義先擱在一旁；當它判斷需要某個功能，就用 Tool Search 像下關鍵字一樣搜尋，命中後才把那一支工具的完整定義載進來。工程圈把這種「要用才揭露」的做法叫 progressive disclosure（漸進式揭露）。

AI 按需搜尋並載入工具的儀表板示意，象徵 Tool Search 機制

效果非常顯著。Anthropic 的數據顯示，這個機制能在保留「完整工具庫都能用」的前提下，把工具定義的 token 開銷砍掉約 85%。前面提到那個優化前要 134,000 token 的配置，開了 Tool Search 之後可以壓到一個零頭。省下來的桌面空間，全部還給「實際思考」，這也是為什麼準確率會跟著上升。

如果你用過 Claude Code（Anthropic 的開發工具），其實已經親眼見過這個機制在運作：當你連了很多工具，畫面上會出現一段「這些工具已就緒、但說明書尚未載入，需要時會自動取用」的提示。那就是 Tool Search 在背後把目錄跟說明書分開管理。底層它是用關鍵字排序（業界常見的 BM25 演算法）或正規表示式來搜尋工具，所以反應很快。

對非工程的老闆而言，你不需要懂這些細節，只要記住一個判斷點：你用的 AI 平台或廠商，有沒有支援這種『按需載入工具』的能力。有，你就可以放心接更多工具；沒有，接越多就越拖累。這也是評估 AI 廠商時，一個很實際、卻很少人問的問題。

除了 Tool Search，還有哪些省 token 的招

Tool Search 解的是「工具說明書太重」這一半問題。另一半是「工具回傳的資料也很重」，你叫 AI 去查一張很大的表，整張表流經記憶體一樣很燒。圍繞這兩個問題，業界這一年發展出好幾種互補的做法。

讓 AI 寫程式去呼叫工具，而不是直接呼叫

Anthropic 另外提出的 程式碼執行（code execution） 是目前省最兇的一招。概念是讓 AI 寫一小段程式去跟工具互動，只把需要的欄位撈回來，中間的大量資料在程式裡就處理掉、不流經記憶體。複雜流程原本可能要 15 萬個 token，這樣做能省下約 98%。Cloudflare 也有類似的 Code Mode，宣稱輸入 token 能降低高達 99.9%。

壓縮工具定義、過濾回傳內容

另外兩招比較直覺：一是 schema 壓縮，把工具說明裡冗長的描述、範例、巢狀結構精簡掉，只留 AI 呼叫時真正需要的參數；二是回應過濾，只跟工具要你需要的那幾個欄位，而不是把整包資料倒回來。兩招都是針對「重量」直接瘦身。

最簡單的一招：把不用的 server 關掉

在你想任何高級技巧之前，最有效的往往是最樸素的：把長期用不到的 MCP server 直接停用，只在真正需要的特定任務或特定 AI 助理上開啟。有實測指出，光是同時開 7 個 server，記憶體就被吃掉三分之一。先做減法，再談優化。

省 token 做法	解決哪個問題	適合誰
Tool Search 按需載入	工具說明書太重（schema bloat）	所有人，多半預設已開
程式碼執行	工具說明 + 回傳資料都太重	有工程能力的團隊 / 廠商
schema 壓縮、回應過濾	定義冗長、回傳資料過大	自建 MCP 整合時
停用不用的 server	工具裝太多、雜訊太高	每一個人，第一步就該做

想知道有哪些 MCP server 值得留、哪些其實可以先關，我們整理過 10 個讓 Claude 更強的 MCP Server 推薦 可以當挑選的起點。

所以「加很多 MCP」還該不該怕？給老闆的判斷準則

回到你最初的疑問。把前面拆解完，答案其實很清楚：會不會燒 token，取決於你的 AI 平台有沒有按需載入；該不該怕，取決於有沒有人在管它連了什麼。我們的判斷是，對中小企業來說，真正的風險從來不在「連太多 MCP」這個技術現象，而在「沒有人盤點過這些工具、也沒人在看成本」這個管理空缺。

工具定義塞滿 context window 的抽象示意，象徵 context 膨脹

如果你正在評估要不要讓 AI 助理接更多工具、或正在挑 AI 廠商，下面這幾個問題會幫你快速判斷風險高低：

圖表載入中…

把它落成三條可執行的準則。第一，挑平台先問『有沒有按需載入』這一條就決定了你之後接工具會不會痛。第二，定期盤點、勇敢做減法，三個月沒用到的 server 就先關掉，需要再開。第三，把 token 成本當成一個要看的數字，而不是等帳單來才嚇一跳。這三條跟你管任何一項公司資源的邏輯，其實一模一樣。

想更深入了解 MCP 在企業端怎麼選型、自架還是外接 SaaS 怎麼決定，可以接著看 MCP server 採購：自架 vs 外接的 6 個決策；如果你連 RAG、Agent 這些詞也想一起搞懂，老闆級 AI 用語對照表 是個輕鬆的入門。

工具的名字和說明是誰決定的？在 claude.ai 你能改什麼

講到這裡，有個很實際的延伸問題：Tool Search 拿來比對的那串「工具名稱加一句說明」，到底是誰寫的、你能不能自己改？答案要看你的身分。先講結論，這串文字是寫那個工具的人（也就是 MCP server 的開發者）在伺服器端定義好的，透過 MCP 協定送給 AI。如果你只是 claude.ai 的一般使用者，等於是「接上別人做好的工具」，沒辦法在介面上改它的名字或說明。

你的身分	能不能改工具的名稱／說明	在哪裡做
claude.ai 一般使用者	只能整支工具開或關，改不了文字	Settings > Connectors 加／移除；對話框「Search and tools」選單開關個別工具
自架 MCP server 的開發者	可以，完全掌控	改 server 程式碼裡的工具定義（name / description）
用 Claude API 或 Claude Code	可以，完全掌控	API 的工具定義（可一併設 defer_loading）／ Claude Code 的 MCP 設定檔

claude.ai 上新增工具的路徑很單純：到 Settings > Connectors（或直接開 claude.ai/settings/connectors），點「Add custom connector」，填入 MCP server 的名稱和一個公開可連的 HTTPS 網址架在公司內網、VPN 或防火牆後面的伺服器是連不上的。加好之後，你能掌控的是「要不要啟用這個 connector」「對話裡開或關某幾支工具」，但工具本身叫什麼、說明怎麼寫，改不了。

想對「工具叫什麼、說明怎麼寫」有完全控制權，就得從使用者升級成「做工具的人」：自己架一個 MCP server，在程式裡自訂每一支工具的 name 和 description，再到 claude.ai 用 connector 接它。成品照樣在 claude.ai 裡用，但那串文字你說了算。這也是 Tool Search 能不能精準命中你工具的關鍵，名稱和說明寫得越清楚，AI 越容易在需要時找到它。

自架 server 改了工具定義，claude.ai 會自動同步嗎

假設你已經自架了 MCP server，也改好了某支工具的名稱或說明，下一個會踩到的問題是：claude.ai 會自己更新，還是要做什麼動作？這裡有個很容易誤會的地方得先講清楚。

MCP 協定其實設計了一個「工具清單變了」的主動通知機制（規格上叫 notifications/tools/list_changed），讓 server 改動之後可以推一個訊號給 AI，要它重新拉一次工具清單。聽起來很理想，但現實是：目前 Claude 的用戶端（桌面版、Claude Code 都被社群實測過）收到這個通知會直接忽略，並沒有真的接上去。所以你不能指望「對話進行到一半，server 一改就即時同步」這種事。

情境	會不會反映新版工具定義	依據
同一個對話進行中改 server	不會	list_changed 通知 Claude 用戶端尚未實作
開一個全新對話	多半會（網頁版沒有持久狀態，新 session 通常會重抓）	合理推測，官方未白紙黑字保證
Settings > Connectors 停用再啟用 / 移除再重加	最可靠，等於強制重新連線重抓	社群實證
用 Claude 桌面 App	要整個重啟 App 才看得到	社群實證（GitHub issue）

落成操作就是由輕到重四步：先開一個新對話試；沒反映就到 Settings > Connectors 把 connector 停用再啟用；還是舊的就移除再重新加入；用桌面 App 的話直接重啟。多數時候第一、二步就解決了，不必每次都整個重加。

這裡要誠實補一句：Anthropic 官方文件對「工具定義改了之後該怎麼刷新」其實沒有明說，他們的設計假設似乎是「工具定義不太會變動」。MCP 較新版的規格（2025 年底）有加上讓 server 自己宣告「工具清單該快取多久」的欄位（ttlMs、cacheScope），但 claude.ai 有沒有尊重這些設定，官方也還沒證實。所以最保險的習慣是：改完工具定義，就順手去 connector 設定重連一次，把快取的不確定性直接排除掉。想更系統地了解 MCP 在企業端怎麼選型、自架還是外接，可以接著看 MCP server 採購：自架 vs 外接的 6 個決策。

ℹ️我們怎麼看

MCP 的 token 膨脹問題，本質上是 AI 工具生態「從少到多」的成長痛。我們的看法是：3 年後，按需載入會像今天的「自動存檔」一樣，變成所有 AI 平台的標準配備，沒有人會再為它操心。真正會拉開差距的，從來都是另一件事，誰能想清楚「我的業務流程裡，哪幾段值得讓 AI 自動做」，然後只接那幾段真正需要的工具。對中小企業老闆而言，現在不需要追著技術名詞跑，但值得開始問自己一句話：我們公司讓 AI 處理的事，是不是常常裝了一堆工具卻只用到一兩個？想清楚這個，比研究任何協定都有用。

ℹ️我們做過這件事

順帶說一下，這篇講的東西我們公司自己每天都在碰，目前內部就有 20 多個 AI 流程在工作中運轉，每一個都串了不只一個外部工具，所以「工具一多就拖累 AI」這件事，我們是親自踩過、優化過才寫的。在我們的系統客製化與 AI 整合經驗裡，最常見的狀況就是企業一口氣接了太多工具，卻沒人盤點成本與必要性。看到這裡，如果你也在想「這套放到我們公司會是什麼樣子」，我們很樂意聽你聊聊現在的實際情況，一起看看從哪一塊開始最划算。

自我檢測 checklist：你的 AI 工具是不是在偷吃成本？

花兩分鐘對照這五點：①你的 AI 平台說明文件裡，有沒有提到 Tool Search、按需載入或 progressive disclosure？②過去三個月，有沒有人盤點過哪些工具其實沒在用？③你看得到每個月 AI 的 token 或 API 花費嗎？④AI 助理回應有沒有越來越慢？⑤接了工具之後，AI 有沒有反而常挑錯工具？中了兩項以上，就值得停下來檢視一次。需要有人陪你一起盤，可以把現況丟給我們，我們直接告訴你哪裡可以省。

Q連很多 MCP 一定會很燒 token 嗎？

傳統做法上會，因為每個工具的完整定義都會在每一輪對話被載入記憶體，5 到 10 個 server 可能在你提問前就燒掉 10 萬到 20 萬個 token。但只要你的平台支援 Tool Search 這類按需載入機制（多數新平台已預設開啟），閒置的工具就不會持續吃 token，只有真正用到的才會計費。

QTool Search 是什麼？我需要自己設定嗎？

Tool Search 是 Anthropic 在 2026 年 1 月推出的機制，讓 AI 平常只看到工具目錄、需要時才載入完整工具定義，可省下約 85% 的工具 token 開銷。對多數使用者來說它是預設開啟的，不需要自己設定；如果你是用廠商提供的 AI 服務，可以直接問對方有沒有支援這個能力。

QMCP 跟一般的 API 串接差在哪？

簡單說，API 是「一對一」的客製串接，每接一個系統就要寫一套對接；MCP 是「萬用插座」式的標準協定，讓 AI 用同一套方式接上各種工具與資料。代價是它預設會把所有工具資訊都告訴 AI，才衍生出 token 膨脹的問題。更完整的比較可以看我們的 MCP 是什麼專文。

Q我是中小企業老闆，需要懂這些技術細節嗎？

不需要懂實作，但建議掌握一個判斷點：挑 AI 平台或廠商時，問對方「有沒有支援按需載入工具」。有，你就能放心接更多工具；沒有，接越多越慢越貴。另外養成定期盤點、關掉用不到的工具的習慣，就能避開大部分成本問題。

Q除了 Tool Search，還有別的省 token 方法嗎？

有。讓 AI 寫程式去呼叫工具（code execution）可省約 98%；壓縮工具定義、只回傳需要的欄位也能瘦身；而最簡單有效的，是把長期用不到的 MCP server 直接停用，只在需要的任務上開啟。多管齊下效果最好。

Q工具接太多，AI 真的會變笨嗎？

會。工具選項一多，模型容易挑錯或漏用工具。Anthropic 的評測顯示，在工具很多的情境下導入按需載入後，挑對工具的準確率從 49% 提升到 74%。所以控管工具數量不只省錢，也直接影響 AI 好不好用。

Q在 claude.ai 上可以自己改 MCP 工具的名稱或說明嗎？

不行。claude.ai 一般使用者只能在 Settings > Connectors 新增或移除 connector、在對話的「Search and tools」選單開關個別工具，無法編輯工具的名稱或說明，這些是 MCP server 開發者在伺服器端定義的。想自訂就得自己架 MCP server、用 Claude API 定義工具，或用 Claude Code 設定本機 MCP server。

Q我改了自架 MCP server 的工具定義，claude.ai 會自動更新嗎？

不會即時更新。MCP 雖然有「工具清單變更通知」機制，但 Claude 用戶端目前沒實作，所以對話進行中不會同步。最可靠的做法是到 Settings > Connectors 把 connector 停用再啟用、或移除再重加，強制它重新抓一次工具清單；開新對話多半也會重抓；桌面 App 則要整個重啟。

回到最開始那個問題：連很多 MCP 會不會很燒 token？會，但這是個正在被解決的問題，而且解法已經相當成熟。真正值得你花心力的，是想清楚公司到底需要哪些工具、並且讓有經驗的人幫你把成本管好。如果你正打算讓 AI 真的接進公司的流程、又不想踩到「裝一堆卻拖累整體」的坑，歡迎 跟我們聊聊你的 AI 導入需求，或看看我們在 客製化系統開發 上能幫上什麼。先把最痛的那一塊講清楚，我們會直接告訴你值不值得做、怎麼做最省。