Model Context Protocol 贏了。它現在是「無聊的基礎設施層」——78% 的企業 AI 團隊在生產環境跑 MCP，最近更迎來史上最大更新：為「真的大玩家」、成千上萬個 agent 而做的全無狀態重寫。

所以獨立開發者面對一個尖銳的問題：如果這就是標準，我為什麼還要自己寫 API 呼叫？

直接抓 API 的直覺，比行銷話術暗示的更常是對的。下面是規則。

你其實在做兩個決定

大家把「API vs MCP」壓成一個問題，其實是兩個：

  1. 傳輸——位元組怎麼從你的 agent 到那個能力。
  2. 護欄——你的 agent 被允許做什麼。

MCP 不會讓你的 agent 更安全。「阻止它刪光我的雲端硬碟」這個性質，存在於你授予的授權範圍和你暴露的工具介面裡——不在協議裡。一個 scope 收緊的原生 API 呼叫，和一個只暴露 read 工具的 MCP server，做得一樣好。

所以「MCP 更安全」是偽命題。MCP 真正買到的是一致性——agent 和每個 client 都用同一種方式跟每個工具講話。這有價值，但只是有時。

規則

用原生 API、scope 收緊，當：

  • 你是一個 agent、配上少數幾個資源。
  • 你是唯一的消費者，而且會一直是。
  • 護欄就只是收緊一個 token——自己來很簡單。
  • 你要服務商完整原生的介面，不是一層翻譯。

用 MCP，當：

  • 多個 client 或多個 agent 需要同一個資源。
  • 你想換模型或服務商，卻不想重寫呼叫邏輯。
  • 已經有成熟的 server 處理某個棘手環節（認證流程、串流、分頁邊界）。
  • 你在組合很多工具，想要單一呼叫慣例。

為什麼這對獨立開發者最關鍵

MCP 的核心價值是 N×M → N+M 的收縮：與其為每一組 (client, resource) 客製一個整合，不如每個資源建一個 server。這個回報只有在 N 和 M 都大時才成立。

獨立開發者是 N=1。你就是一個 agent、對少數幾個 API 講話。收縮不划算——你只是在服務商上頭多套一層翻譯，而服務商的原生權限本來就在做護欄的工作。層數越少，會壞的東西越少；依賴越少，當規格（像 MCP 的全無狀態重寫）在你腳下移動時，遷移頭痛也越少。

關鍵分歧不是「因為是 MCP」。是：會不會有第二個消費者未來需要這個資源？ 不會，精簡的選擇就是原生 API。會，一致性才開始回本。

Sources

  • Agentic AI Foundation——The 2026 MCP Roadmap（2026）：傳輸擴展性、agent 通訊、治理、企業就緒。
  • VentureBeat——MCP just got its biggest update ever（Michael Nuñez，2026）：無狀態架構、OAuth 加固、12 個月棄用政策、MCP Apps/Tasks 轉正為官方擴展。
  • a2a-mcp.org——MCP 2026 Roadmap（2026）：企業就緒的四大優先；N×M → N+M 的整合收縮框架。
  • Linux Foundation / Agentic AI Foundation 採用數據（2026）：78% 企業 AI 團隊在生產環境用 MCP；約 9,400 個公開 server。