MCP 會取代 API 嗎？一個每天用 MCP 的人的觀察

不會。但它會讓大多數人不再需要直接碰 API。

這篇的核心觀點

• MCP 不是 API 的替代品，它是 API 的「翻譯層」
• MCP 解決的不是「怎麼跟服務溝通」，而是「誰來決定用哪個 API」
• 未來不是「MCP vs API」，而是「AI 透過 MCP 呼叫 API」

先說清楚 MCP 是什麼

如果你要用一個很簡單的比喻：

API 是餐廳的後廨。你可以直接走進去跟廉師說你要什麼，但你得知道廉師的語言、菜單編號、下單格式。

MCP 是服務生。你跟服務生說「我要一個不辣的牵牛麵」，服務生知道怎麼跟後廨溝通。

AI 就是那個服務生。MCP 是服務生和後廨之間的「點菜協議」。

所以 MCP 不會取代 API，就像服務生不會取代廉師一樣。

我每天實際的體驗

我每天透過 MCP 操作 15+ 個 App。一個很具體的感受是：

我已經不記得大部分 API 的細節了。 Gmail 的搜尋語法是什麼？我不知道，我只要說「幫我找昨天從 XX 寄來的信」就好。Notion 的 block type 有哪些？不重要，我只要說「在這個頁面加一個表格」。

MCP 把 API 的複雜度藏在 AI 後面了。你跟 AI 說人話，AI 跟 API 說機器話。

但 MCP 有它自己的問題

說完優點，說問題。

工具描述決定了 AI 會不會用。 MCP server 提供的 tool description 如果寫得不清楚，AI 就不知道什麼時候該用它。這跟 API 文件寫得不好一樣，問題只是轉移了，沒有消失。

標準化還不夠。 每個 MCP server 的 tool 命名、參數格式、錯誤處理都不一樣。你連接五個不同人寫的 MCP server，就像在五個不同風格的餐廳點菜一樣混亂。

效能問題。 AI 每次都要「思考」該用哪個工具，這比直接呼叫 API 慢。對於需要毫秒級回應的場景（像是即時通訊），MCP 還不夠快。

我的判斷

未來五年：

• 大多數人不會再直接用 API，就像大多數人不會直接寫 SQL 一樣
• API 依然存在，但被藏在 MCP 後面
• MCP server 的品質會變成競爭力——誰的 tool description 寫得好、誰的錯誤處理做得好，誰的 AI 就用得更順
• 「一條 MCP URL 連接所有 App」會變成標準，而不是特殊功能

結論

MCP 不會取代 API。但它會讓「直接碰 API」這件事變得越來越不必要。對大多數人來說，這是好事。