MCP is Dead：一個保險科技團隊用實測數據說明為什麼 CLI 優先比全連 MCP 更實際
整理版優先睇
Quandri實測發現MCP token消耗高達上下文窗口10-16%，首次調用慢9.4倍，提出CLI優先+Skills按需加載作為更實際方案
呢篇文章係Quandri嘅後端工程師Chloe Kim分享嘅實測報告。佢哋團隊用緊MCP嚟連接AI同開發工具，但發現實際表現同宣傳差好遠。佢哋測咗四個MCP Server嘅token消耗，結果發現單係工具定義就已經佔咗Claude 10.5%嘅上下文，GPT-4o更高達16.5%。仲有首次調用慢9.4倍嘅問題。
為咗改善呢個情況，Chloe提出兩個替代策略：CLI優先同Skills模式。CLI優先即係直接用現成嘅命令行工具（例如curl、psql），唔經MCP中間層；Skills模式就係按需加載工具定義，唔係一次過攤曬所有工具出嚟。佢哋團隊實際採用咗混合方案，日常用Bash/CLI，複雜工作流用Skills，只有冇CLI替代嘅服務先用MCP。
文章結論係MCP並冇完全死，但適用場景好窄，例如冇CLI嘅服務、非開發者用戶、生產數據庫。佢哋認為教會AI點樣用好一個工具，比連接所有工具更重要。呢篇文章用實測數據提供咗一個好實際嘅反思，尤其適合需要快速迭代嘅開發團隊。
- MCP嘅token消耗驚人：四個Server共77個工具，吃掉約21,077 tokens，佔Claude 10.5%上下文，GPT-4o 16.5%。
- MCP效能懲罰明顯：首次調用比直接API慢9.4倍，每次調用慢3倍，增加除錯難度。
- CLI方式極省token：同樣查一個Linear issue，MCP用12,957 tokens，CLI只需約200 tokens，差距65倍。
- 替代方案：CLI優先（直接用curl/psql等）同Skills模式（按需加載工具定義），釋放token並消除初始化失敗。
- MCP仍有價值嘅場景：冇CLI替代嘅服務、非開發者用戶、生產數據庫；其他情況建議用CLI+Skills。
CLI優先+Skills模式混合方案
日常用Bash/CLI，多步驟工作流用Skills，只有冇CLI替代或需要統一認證嘅服務先保留MCP。
MCP嘅token消耗——工具定義佔咗一成以上上下文
Quandri團隊測咗技術棧入面四個MCP Server嘅token消耗。Linear有42個工具，佔約12,807 tokens；Notion有14個工具，約4,039 tokens；Slack有12個工具，約3,792 tokens；Postgres有9個工具，約438 tokens。
四個Server加埋77個工具，總共食咗約21,077 tokens。Claude嘅200K上下文窗口，淨係工具定義就佔咗10.5%；GPT-4o嘅128K窗口更慘，佔到16.5%。
效能問題：慢9.4倍嘅首次調用同調試難度
MCP Server引入咗額外架構開銷：獨立進程管理、認證失敗、會話中途崩潰、響應變慢。有人攞Jira MCP同直接調REST API做基準測試，發現MCP每次調用慢3倍，計埋初始化嘅首次調用慢9.4倍。
直接對比：查一個Issue，Token差距65倍
Quandri做咗個直接對比：用MCP查一個Linear issue，消耗約12,957 tokens；用CLI做同樣嘅事，只需要約200 tokens。相差65倍。
原因好簡單。MCP需要先加載曬所有42個工具嘅定義，然後模型從中揀合適嘅工具，再發起調用。CLI方式直接寫一行curl命令，帶上GraphQL query，搞掂。
替代方案：CLI優先同Skills按需加載
第一個策略係CLI優先。大部分服務都有現成嘅命令行工具，人和AI都用到。唔需要額外工具定義，唔佔上下文，除錯都直觀。例如Linear用curl + GraphQL，Postgres用psql，Slack用webhook。
第二個係Skills模式。核心思路係按需加載，只喺需要嘅時候先將工具說明拉入上下文。用文章嘅比喻：MCP係將十份菜單攤滿成張枱，Skills係同圖書管理員講你要邊本書，淨係攞嗰本。上下文佔用從固定變成按需，唔用嘅工具唔消耗任何token。
MCP並未完全死：仲有呢三個場景值得用
- 1 冇CLI替代品嘅服務：有些工具淨係提供Web界面同API，冇命令行客戶端，呢個時候MCP係合理嘅橋接層。
- 2 非開發者用戶：唔係個個都用終端，MCP俾唔掂命令行嘅人提供咗同AI工具交互嘅界面。
- 3 生產數據庫：MCP嘅查詢安全護欄同憑證管理喺生產環境有實際價值，比直接俾AI一個psql連接可靠得多。但本地開發或個人數據庫就冇必要，Skills加CLI更輕快。
文章最後嘅結論係：教會AI點樣用好一個工具，比把所有工具都連上去更重要。呢個反思值得每個用緊MCP嘅團隊停低諗一諗。
Quandri 係一間保險科技公司，佢哋嘅後端工程師 Chloe Kim 用實測數據寫咗篇文章，標題好直接：MCP is Dead。MCP 俾人叫做「AI 生態嘅 USB-C」，但喺日常開發入面，呢個協議嘅實際表現同宣傳相差都幾遠
Quandri 測咗自己技術棧入面四個 MCP server 嘅 token 消耗。Linear 有 42 個工具，大約食咗 12,807 tokens；Notion 有 14 個工具，大約食咗 4,039 tokens；Slack 有 12 個工具，大約食咗 3,792 tokens；Postgres 有 9 個工具，大約食咗 438 tokens。四個 server 加埋總共 77 個工具，總共食咗大約 21,077 tokens
Claude 嘅 200K 上下文窗口，淨係工具定義就佔咗 10.5%。GPT-4o 嘅 128K 窗口仲慘，佔到 16.5%。呢啲 token 唔係用嚟推理，純粹係喺度描述「我可以做到啲乜嘢」
仲誇張嘅係 Linear 嘅 save_issue 呢一個工具就要大約 619 tokens，但大多數用戶根本用唔到 42 個工具入面嘅大部分
慢 9.4 倍嘅首次調用
MCP server 帶嚟咗額外嘅架構開銷：獨立進程管理、認證失敗、會話中途崩潰、回應變慢。有人攞 Jira MCP 同直接 call REST API 做咗基準測試，MCP 每次調用慢 3 倍，計埋初始化嘅首次調用慢 9.4 倍
對於需要快速迭代嘅開發場景，呢個延遲好難接受。CLI 工具直接 call API，冇中間層，出錯可以直接睇報錯信息就查到。MCP 多咗一層抽象，除錯複雜程度亦都跟住升
65 倍嘅 token 差距
Quandri 做咗一個直接對比：用 MCP check 一個 Linear issue，消耗大約 12,957 tokens。用 CLI 做同一樣嘅嘢，只需要大約 200 tokens。相差 65 倍
原因好簡單。MCP 需要先加載曬所有 42 個工具嘅定義，然後模型從中揀合適嘅工具，再發起調用。CLI 方式直接寫一行 curl 命令，帶埋 GraphQL query，搞掂
大多數 MCP server 對接嘅服務本身就有成熟嘅 CLI 同 API。MCP 將呢啲能力重新包裝一次，但係甩咗除錯嘅簡單性同可組合性
替代方案：CLI 優先 + Skills 按需加載
Quandri 提出兩個替代策略
第一個係 CLI 優先。大部分服務都有現成嘅命令行工具，人同 AI 都用得。唔需要額外嘅工具定義，唔佔上下文，除錯亦都直觀。Linear 用 curl + GraphQL，Postgres 用 psql，Slack 用 webhook
第二個係 Skills 模式。核心思路係按需加載，只係喺需要嘅時候先至將工具說明拉入上下文。用文章嘅比喻：MCP 係將十份菜單攤曬成張枱，Skills 係同圖書管理員講你要邊本書，淨係攞嗰本。上下文佔用由固定變成按需，唔用嘅工具唔會消耗任何 token
Quandri 實際落地嘅係混合方案。日常用嘅工具行 Bash/CLI，多步驟工作流用 Skills，只有冇 CLI 替代或者需要統一團隊認證嘅服務先保留 MCP
MCP 未完全死，但適用場景好窄
Chloe Kim 承認三種場景下 MCP 仍然有價值
冇 CLI 替代品嘅服務。有啲工具淨係提供 Web 界面同 API，冇命令行客戶端，呢個時候 MCP 係合理嘅橋接層
非開發者用戶。唔係個個都識用 terminal，MCP 俾唔掂命令行嘅人提供咗同 AI 工具互動嘅界面
生產數據庫。MCP 嘅查詢安全護欄同憑證管理喺生產環境有實際價值，比起直接俾 AI 一個 psql 連接可靠得多。但本地開發或者個人數據庫就冇必要，Skills 加 CLI 輕快好多
文章最後嘅結論係：教識 AI 點樣用好一個工具，比起將所有工具都連上去更加重要。Quandri 用 Skills 取代 MCP server 之後，釋放出大約 21,000 tokens，同時消除咗初始化失敗嘅問題
Quandri 是一家保險科技公司，他們的後端工程師 Chloe Kim 用實測數據寫了一篇文章，標題很直接：MCP is Dead。MCP 被稱為"AI 生態的 USB-C"，但在日常開發中，這個協議的實際表現和宣傳差距不小
Quandri 測了自己技術棧裏四個 MCP server 的 token 消耗。Linear 42 個工具佔約 12,807 tokens，Notion 14 個工具佔約 4,039 tokens，Slack 12 個工具佔約 3,792 tokens，Postgres 9 個工具佔約 438 tokens。四個 server 加起來 77 個工具，總共吃掉約 21,077 tokens
Claude 的 200K 上下文窗口，光是工具定義就佔了 10.5%。GPT-4o 的 128K 窗口更慘，佔到 16.5%。這些 token 不是用來推理的，純粹是在描述"我能做什麼"
更誇張的是 Linear 的 save_issue 這一個工具就要約 619 tokens，但大多數用戶根本用不到 42 個工具裏的大部分
慢 9.4 倍的首次調用
MCP server 引入了額外的架構開銷：獨立進程管理、認證失敗、會話中途崩潰、響應變慢。有人拿 Jira MCP 和直接調 REST API 做了基準測試，MCP 每次調用慢 3 倍，算上初始化的首次調用慢 9.4 倍
對於需要快速迭代的開發場景，這個延遲很難接受。CLI 工具直接調 API，沒有中間層，出錯了直接看報錯信息就能排查。MCP 多了一層抽象，調試複雜度也跟着上去了
65 倍的 token 差距
Quandri 做了一個直接對比：用 MCP 查一個 Linear issue，消耗約 12,957 tokens。用 CLI 做同樣的事，只需要約 200 tokens。差了 65 倍
原因很簡單。MCP 需要先加載所有 42 個工具的定義，然後模型從中選擇合適的工具，再發起調用。CLI 方式直接寫一行 curl 命令，帶上 GraphQL query，完事
大多數 MCP server 對接的服務本來就有成熟的 CLI 和 API。MCP 把這些能力重新包裝了一遍，但丟掉了調試的簡單性和可組合性
替代方案：CLI 優先 + Skills 按需加載
Quandri 提出兩個替代策略
第一個是 CLI 優先。大部分服務都有現成的命令行工具，人和 AI 都能用。不需要額外的工具定義，不佔上下文，調試也直觀。Linear 用 curl + GraphQL，Postgres 用 psql，Slack 用 webhook
第二個是 Skills 模式。核心思路是按需加載，只在需要的時候才把工具說明拉進上下文。用文章裏的比喻：MCP 是把十份菜單攤滿整張桌子，Skills 是跟圖書管理員說你要哪本書，只拿那一本。上下文佔用從固定變成按需，不用的工具不消耗任何 token
Quandri 實際落地的是混合方案。日常用的工具走 Bash/CLI，多步驟工作流用 Skills，只有沒有 CLI 替代或者需要統一團隊認證的服務才保留 MCP
MCP 沒有完全死，但適用場景很窄
Chloe Kim 承認三種場景下 MCP 仍然有價值
沒有 CLI 替代品的服務。有些工具只提供 Web 界面和 API，沒有命令行客戶端，這時候 MCP 是合理的橋接層
非開發者用戶。不是每個人都會用終端，MCP 給不碰命令行的人提供了和 AI 工具交互的界面
生產數據庫。MCP 的查詢安全護欄和憑證管理在生產環境有實際價值，比直接給 AI 一個 psql 連接靠譜得多。但本地開發或個人數據庫就沒必要了，Skills 加 CLI 更輕快
文章最後的結論是：教會 AI 怎麼用好一個工具，比把所有工具都連上去更重要。Quandri 用 Skills 替換 MCP server 後，釋放了約 21,000 tokens，同時消除了初始化失敗的問題