面對大型語言模型（LLM）的介面選擇，傳統命令列介面（CLI）因其顯著的權杖成本效益與廣泛相容性，正逐漸超越模型上下文協定（MCP），成為微軟與Google等巨頭的預設選項，促使開發者需重新評估兩者在效率與功能上的取捨。
隨著人工智慧（AI）應用日益普及，開發者在為大型語言模型（LLM）選擇操作介面時面臨關鍵決策：是採用標準化的模型上下文協定（Model Context Protocol, MCP），還是傳統的命令列介面（Command Line Interface, CLI）？近期趨勢顯示，CLI因其顯著的成本效益與廣泛相容性，正逐漸成為主流選擇，連科技巨頭微軟（Microsoft）與Google也紛紛將其推為預設介面。
《Security Boulevard》報導指出，微軟近期在既有的MCP伺服器之外，推出了Playwright的CLI版本，主要考量便是權杖效率。根據微軟Playwright的說明文件，現代的程式碼生成AI代理（coding agents）日益偏好CLI，主因是其可避免在上下文中載入龐大的工具綱要（schema）。此舉大幅降低了權杖消耗，例如Playwright的基準測試顯示，MCP版本每次測試需約11.4萬個權杖，而CLI版本僅需約2.7萬個權杖，兩者相差四倍。
同時，Google也推出了針對旗下所有Google Workspace服務的單一CLI工具「gws」，並稱其「為人類與AI代理打造」。儘管MCP模式仍作為選配提供，但兩大科技公司皆將CLI定為預設，將MCP定位為附加層。這反映出業界對於優化AI代理互動成本與效率的共識。
報導作者霍爾頓·休伊特（Holden Hewett）分享個人經驗表示，他曾將個人AI工作流程從Obsidian的MCP伺服器轉移至CLI，因為MCP繞過了Obsidian的類型驗證，導致檔案移動後連結失效，並需重建模板。相較之下，Obsidian CLI允許LLM如同人類使用者般，透過與桌面應用程式相同的內部API操作Obsidian，確保了驗證、索引與連結管理。
CLI的主要優勢包括：權杖成本較低、每次呼叫皆為無狀態（stateless）設計，避免了MCP會因累計狀態填滿上下文視窗而導致模型錯誤或重複的問題。此外，CLI具有更廣泛的適用性，可在Claude Code、Cursor、CI管線、排程作業、Shell腳本及終端機等多種環境下運作。而MCP工具則僅限於支援MCP客戶端的環境，例如無Shell存取權限的Claude Desktop或沙盒式瀏覽器代理。
然而，MCP並非毫無用處。它提供標準化、具型別（typed）的介面，使工具使用在不同客戶端與模型間具備可移植性，且在多個AI代理協調運作的即時會話中，MCP在處理持久化共享狀態方面表現更佳。MCP協定已於今年稍早捐贈給Linux基金會，顯示其作為標準的潛力。
面對這兩種介面的選擇，霍爾頓·休伊特建議，開發者在建構面向AI的工具時，應自問：「AI代理實際需要什麼？以及提供它最簡單的方法是什麼？」這將有助於在效率、成本與功能之間取得平衡。