Mcp2cli：適用於所有 API 的通用 CLI，比原生 MCP 節省 96-99% 的 Token 消耗

背景

隨著大型語言模型（LLM）與外部工具結合的應用普及，模型上下文視窗（Context Window）的消耗成為開發者面臨的重大挑戰。mcp2cli 是一個旨在解決此問題的工具，它能將模型上下文協議（MCP）伺服器或 OpenAPI 規範在運行時轉換為命令列介面（CLI），藉此大幅減少因注入完整工具架構（Tool Schemas）而產生的 Token 浪費。

社群觀點

Hacker News 社群對於 mcp2cli 的出現反應兩極，討論核心圍繞在 Token 節省的實質意義、工具的必要性以及 MCP 協議本身的設計缺陷。支持者如 philipp-gayret 認為，將 MCP 轉化為 Bash 命令能發揮高能力代理人（如 Claude 或 Cursor）擅長編寫腳本的優勢，使工具具備更強的組合性，解決了早期 MCP 釋出時就存在的上下文過載問題。然而，許多資深開發者對此類「封裝再封裝」的趨勢感到疲勞。Doublon 諷刺地指出，業界從 curl、HTTP 到 OpenAPI，為了 AI 創造了 MCP，現在卻又要將 MCP 包裝回 CLI，這種技術循環令人困惑。

針對 Token 節省這一核心賣點，stephantul 與 hrmtst93837 等評論者提出了嚴厲的質疑。他們認為 Token 數量不應是唯一的衡量指標，更重要的是在減少 Token 的同時，是否能維持工具呼叫的準確性、延遲表現與開發者體驗。部分用戶甚至批評該專案的說明文件帶有濃厚的 AI 生成感，這降低了技術社群對其數據真實性的信任。此外，關於 LLM 如何在未知 CLI 命令的情況下進行探索，社群也展開了技術細節的討論，普遍認為模型需要透過特定的技能引導或預設的列表命令來實現按需發現。

另一派討論則深入探討了 MCP 存在的必要性。DieErde 質疑為何不直接使用網頁存取或簡單的 URL 列表，而要採用複雜的 MCP 協議。對此，Phlogistique 與 SyneRyder 提供了反駁觀點，強調 MCP 的核心價值在於授權與存取控制。若僅給予模型完整的網頁存取權，可能導致數據外洩或模型執行未經授權的操作；MCP 則能作為閘道器，驗證參數並限制模型僅能執行特定功能。儘管如此，仍有評論者如 rvz 堅持認為 MCP 是一個設計有缺陷的標準，直接開發與 AI 代理協作的專案專屬 CLI 或許是更簡潔的作法。

最後，社群也觀察到類似工具的激增現象。jancurn 等人列舉了十多個功能相仿的 MCP CLI 工具，顯示出這是一個競爭激烈的領域。雖然 mcp2cli 宣稱能達到 96% 以上的節省率，但社群普遍認為，唯有在確保模型推理品質不下降的前提下，這些節省才有實質的商業價值。

延伸閱讀

在討論串中，開發者們分享了多個與 MCP 節省 Token 或 CLI 轉換相關的替代方案與參考資源：

• mcporter：另一個將 MCP 伺服器轉換為工具定義的專案。
• CLIHub：啟發 mcp2cli 的原始專案，專注於 CLI 與 MCP 的成本分析。
• Anthropic Tool Search：Anthropic 官方推出的延遲載入方案，旨在減少初始上下文壓力。
• dw2md：針對特定 Wiki 系統開發的轉換工具，展現了更細粒度的處理方式。
• max：透過數據本地同步與通用查詢語言來減少 API 限制與 Token 消耗的實驗性專案。