MCP 工具額外成本實測：26 個工具，每次呼叫 $0.03
目錄
只要把一台 MCP 伺服器接上 agent，還沒開始執行任何工作，每次呼叫就已經產生成本：GitHub 伺服器提供的 26 個工具，會讓每次 Claude Opus 4.8 呼叫多花 $0.0302，不論實際有沒有使用工具。若不查看計量資料，很難發現這筆成本。成本高低也更取決於使用哪個模型，而不是接了多少工具，且其中大部分都能透過快取省下。我們量測了整條路徑：五個模型系列、五台實際的 MCP 伺服器、從 0 到 40 個工具的合成階梯測試，以及能降低帳單的快取與精簡方法。
TL;DR
- 每次 API 呼叫都會把工具定義重新計為輸入 token；在 Claude Opus 4.8 上，一個小型工具實測占 401 個 token。
- 相同工具集在 Claude 上使用的 token 是 GPT-5.6 的 2.7x；實測每個工具分別為 173 與 64 個 token。
- 實際的 GitHub MCP 伺服器有 26 個工具，在 Opus 4.8 上每次呼叫為 $0.0302，在 Gemini 3.6 Flash 上則為 $0.0029，相差 10x。
- 明確設定快取可將持續攜帶的工具區塊成本降至十分之一，但低於快取門檻的工具集無法快取，而且只要變更一個工具，整個區塊都會重新計費。
MCP 伺服器如何轉換成輸入 token？
整個過程分成三個階段，只有最後一個階段會產生成本，卻會在每次呼叫重複發生。先界定範圍：MCP 伺服器提供三種基本項目，分別是工具、資源與提示。只有工具會持續產生固定成本，因為 API 的 tools 參數必須在每次請求中攜帶所有 schema。資源與提示沒有各自的 API 欄位，只有在內容實際載入對話時才會占用 token。第一階段是 MCP 協定本身：agent 用戶端透過 JSON-RPC 向伺服器呼叫 tools/list 並取得 schema。這在每個工作階段只會執行一次，不會接觸模型。第二階段是用戶端將這些 schema 轉成 API 的 tools 參數，並移除 annotations、outputSchema 等 MCP 專用欄位；這一步仍然免費。第三階段才會產生成本：由於 API 無狀態，模型不會記得有哪些工具，因此供應商必須在每次請求時，把這些 schema 轉成隱藏的提示文字。不論工具是否實際使用，這段文字每次呼叫都會按完整輸入費率計費。
最小的實證如下：在 Opus 4.8 上，使用者訊息只有「Reply OK」的請求會消耗 11 個提示 token。加入一個規模不大的 get_weather 工具，包含兩個參數與一行描述後，同一個請求會消耗 412 個 token。只要每次呼叫都帶上這個工具，就會固定增加 401 個 token，也就是 $0.002。這與實際傳送的內容並不成比例：工具 JSON 本身只有約 130 個文字 token，但經供應商轉換後，數量幾乎增加到三倍。
每個模型上的單一工具成本是多少？
模型造成的差異，遠高於多數團隊的預期。我們將完全相同的合成工具集送進五個模型系列。每個工具包含三個參數與一行描述，工具數量則從 0 逐步增加到 40，最後根據計費差額得出以下結果：
| 模型 | 固定額外成本（啟用工具） | 每個工具的邊際成本 | 40 個相同工具 |
|---|---|---|---|
| Claude Opus 4.8 | 290 | 173 | 7,210 |
| GLM 5.2 | 96 | 120 | 4,896 |
| Kimi K3 | 37 | 99 | 3,997 |
| Gemini 3.6 Flash | ≈0 | 72 | 2,871 |
| GPT-5.6 Terra | 98 | 64 | 2,658 |
相同工具的差距達 2.7x：Claude 產生的工具框架文字最長，GPT-5.6 最短。工具 JSON 與實際計費量之間的關係也沒有固定方向。若以傳輸內容位元組數除以四做粗略估算，Claude 的計費量約為該估值的 1.36x，GPT-5.6 與 Gemini 則只有約一半。不同模型系列無法共用工具區塊的 token 估算，因此應依模型編列預算，而不是只看 schema。
實際 MCP 伺服器每次呼叫要花多少錢？
以下列出官方 MCP 儲存庫中五台未經修改的實際伺服器。我們以標準欄位對應方式轉換，並量測每次呼叫持續攜帶工具所產生的額外成本：
| MCP 伺服器（工具數） | Opus 4.8 | GPT-5.6 Terra | Gemini 3.6 Flash | Kimi K3 | GLM 5.2 |
|---|---|---|---|---|---|
| GitHub (26) | 6,043 tok / $0.0302 | 2,076 / $0.0052 | 1,931 / $0.0029 | 3,152 / $0.0095 | 4,077 / $0.0022 |
| Filesystem (14) | 2,785 / $0.0139 | 1,254 / $0.0031 | 1,200 / $0.0018 | 1,574 / $0.0047 | 1,772 / $0.0010 |
| Everything (13) | 1,942 / $0.0097 | 798 / $0.0020 | 663 / $0.0010 | 970 / $0.0029 | 1,176 / $0.0006 |
| Memory (9) | 1,670 / $0.0083 | 554 / $0.0014 | 491 / $0.0007 | 815 / $0.0024 | 1,057 / $0.0006 |
| Sequential-thinking (1) | 1,764 / $0.0088 | 912 / $0.0023 | 815 / $0.0012 | 870 / $0.0026 | 1,015 / $0.0006 |
最後一列反映出兩個重點。Sequential-thinking 只提供一個工具，但在五個模型系列中的四個上，成本仍高於提供九個工具的 Memory，因為它唯一的工具描述非常長：真正該看的不是工具數量，而是轉換後的大小。第一列則常讓 agent 開發者意外：在 Opus 4.8 上，讓 GitHub 工具集跟著一段包含 10 次呼叫的 agent 執行流程，還沒做任何實際工作就會花費 $0.30；Gemini 則是 $0.03，整整相差一個數量級。GLM 5.2 的 token 數量超過 Gemini 兩倍，但換算成金額後還更低。較低的牌價足以抵銷冗長的轉換結果，因此 token 與金額要分開估算。
Agent 實際會使用工具集中的多少工具？
每次呼叫通常只會用到很少一部分，因此這筆成本特別不划算。在我們 agent 測試套件的工具情境中，一組包含 8 個工具的工具集會跟著典型執行流程中的三次呼叫，但每次最多只呼叫一個工具：為了使用一個工具，每次呼叫仍要支付八個 schema 的成本。按照 Opus 4.8 的實測費率，這個 8 工具區塊每次呼叫約占 1,674 個 token，每段執行流程光攜帶 schema 就要消耗約 5,000 個 token。工具迴圈情境已經算是較有利的案例：共有三個工具，而且幾乎每次呼叫都會用到；即使如此，整個區塊仍會跟著迴圈的全部四到五次呼叫重新傳送。從紀錄可歸納出一項通則：每次呼叫通常不會使用超過一個工具，因此工具集的單次呼叫成本取決於接了哪些工具，而不是 agent 實際做了什麼。
快取能抵銷工具成本嗎？
在適合的模型上，大部分可以，但我們實測發現三個明顯限制。在 Claude Opus 4.8 上，工具區塊是可直接快取的前綴：將最後一個工具標記為 cache_control 後，我們的 20 工具區塊只需寫入一次，包含 3,682 個 token，寫入費率為 1.25x；後續每次呼叫都以 0.1x 的費率從快取讀取，讓實際攜帶成本降低 90%。Kimi K3 的自動快取效果更好，而且不需設定：第二次呼叫時，區塊的 2,112 個 token 中有 2,048 個來自快取，占 97%，並維持其常見的 256-token 區塊方式。根據我們對該系列首日進行的量測，GPT-5.6 的明確中斷點 也採用相同定價模式，寫入為 1.25x，讀取為 0.1x。至於 Gemini 的隱式快取，結果與我們先前的其他量測一致：針對工具區塊進行三次預熱探測，命中次數仍為零。這類折扣只能當成額外回饋，不能納入固定規畫。
以下是三個限制。第一是最低門檻：Claude 上的 2 工具區塊約占 655 個 token，低於 1,024-token 的快取下限。因此，即使明確標記，小型工具集仍完全無法快取。能否使用這項手段，要看各模型的最低門檻。第二是變動性：工具區塊位於提示的最前端，因此只要變更工具清單，後方所有快取都會失效。我們直接量測了這項代價：在 Claude Opus 5 上，向已快取的 20 工具集合新增一個工具，會讓整個 4,082-token 區塊按較高的寫入費率重新寫入。工作階段內應固定工具清單，否則每次變更都要支付重寫成本。第三，Anthropic 為 Opus 5 提供的對話中途變更工具 beta，目的正是放寬這項固定清單的要求，允許在不同回合之間變更工具而不讓快取失效。對大量使用工具的 agent 而言，這項功能值得持續關注。
如何縮小工具區塊？
先刪參數，再精簡文字。在我們的 20 工具區塊中，把描述縮成簡短的單一子句可節省 10%；將每個工具從三個參數減為一個，可節省 34%；兩者同時調整可節省 44%，從 3,768 個 token 降至 2,128 個。大部分 token 都花在參數 schema，包括名稱、型別與巢狀描述。這與一般直覺相反：與其只潤飾描述、任由 schema 持續膨脹，不如先精簡 schema。
效果更大的做法，是不要連接用不到的工具。每接上一台 MCP 伺服器，它的完整工具區塊就會出現在每次呼叫中；設定檔多加一行，成本就可能翻倍。如果用戶端支援篩選，可以只註冊伺服器的部分工具，額外成本也會大致按比例下降。若 GitHub 伺服器的 26 個工具只保留五個，依該伺服器的平均工具大小估算，Opus 4.8 的 $0.0302 可降至 $0.007。若系統會使用多個模型系列，也別忘了前述 2.7x 的差距：同一個 agent 從 Gemini 改用 Claude，若沒有重新估算預算，工具攜帶的 token 成本會接近三倍。
常見問題
MCP 本身會增加 token 成本嗎？
不會。MCP 協定、探索、JSON-RPC 與工具呼叫流程都不會接觸模型，因此不產生費用。只有在用戶端把伺服器的 schema 傳入 API 的 tools 參數後，供應商才會在每次呼叫時將其重新轉成計費的提示文字。MCP 帶來的影響是規模：原本只需一行設定就能接上 26 個工具，之後每次呼叫也都會攜帶這 26 個 schema。
未使用的工具也會產生成本嗎？
會，成本與實際使用的工具完全相同。模型必須在每次呼叫時讀取所有 schema，才能知道有哪些工具可以呼叫。我們的 agent 測試套件紀錄顯示，每次呼叫最多只會使用一個工具，但每次仍按完整工具集計費。已連接但閒置的伺服器只會增加攜帶成本。快取可以降低這筆費用，但只有精簡工具集或中斷連線才能完全移除。
MCP 資源與提示會像工具一樣消耗 token 嗎？
不會。只有工具會產生每次呼叫的攜帶成本，因為每個請求都會透過 tools 參數重新傳送所有 schema。只有當用戶端讀取資源並將內容插入對話時，資源才會計費。這時它只是一般輸入，定價方式與任何檢索到的文件相同，也應採用相同的分層原則：經常變動的資源內容應放在快取中斷點之後。提示範本同樣只會在呼叫時，以其產生的文字內容計費。已連接伺服器中未使用的資源與提示不會產生成本，因此 MCP 整合出現在帳單上時，首先要稽核的是工具。
變更工具清單會讓提示快取失效嗎？
會，而且是全部失效。工具區塊會轉換到提示最前端，因此任何變更都會重寫該區塊，以及其後方所有已快取內容。我們實測只新增一個工具，就會讓 4,082-token 區塊按 1.25x 的較高費率重新計費。每個工作階段都應固定工具清單，並將工具清單變更集中批次處理。Anthropic 的對話中途變更工具 beta 正是為了消除 Opus 5 上這項成本，值得持續關注。
量測日期為 2026-07-31，透過 Synthorai 閘道進行：涵蓋合成工具階梯測試（0-40 個工具，n=2），以及五個模型系列上的五組實際 MCP 伺服器工具集；schema 透過 JSON-RPC tools/list 從官方伺服器即時擷取。快取測試採用加鹽前綴與逐次呼叫快取明細；agent 使用率則取自我們的 agent 成本研究所用測試套件紀錄。GPT-5.6 的快取倍率引用我們首日發布的成本指南量測資料。金額為從閘道計量資料讀取的計費差額，並按牌價中的輸入費率計算。費率與轉換行為可能變更，請以自己的用量紀錄驗證。