從 10 萬到 9700 萬下載：MCP 如何在 14 個月內變成 AI 工具連接的 USB

2024 年 11 月，Anthropic 發了一篇不起眼的公告，介紹一個叫 Model Context Protocol 的東西。SDK 月下載量大約 10 萬。

14 個月後的今天，MCP 月下載量 9,700 萬。970 倍。OpenAI、Google、Microsoft、AWS 全部原生支援。治理權捐給了 Linux Foundation 底下的 Agentic AI Foundation。

10 萬到 9,700 萬，一年多一點。我想聊聊這件事為什麼值得開發者認真看待。

問題不是技術，是膠水

2024 年底的 AI 開發長這樣：你的 LLM 需要讀 GitHub issue，你寫一個 function call。需要查 Slack 訊息，再寫一個。需要讀資料庫，再來一個。每個整合都是客製化的，每換一個 LLM 供應商就要重寫一遍。

這跟 USB 出現之前的電腦周邊一模一樣。印表機用 parallel port，滑鼠用 serial port，鍵盤用 PS/2。每種設備一種接口，每種接口一個驅動程式。

MCP 做的事情就是定義一個統一接口：LLM（client）透過標準化的 JSON-RPC 協議，連接到任何 MCP server。server 負責跟外部系統溝通，client 不需要知道底層細節。

LLM Application (Client)
    ↓ JSON-RPC（標準協議）
MCP Server（GitHub）
MCP Server（Slack）
MCP Server（PostgreSQL）
MCP Server（你自己寫的任何東西）

一個 client 連多個 server，一個 server 服務多個 client。寫一次就到處用。

三個轉折點

第一個轉折：Cursor 一鍵安裝。 2025 年初，Cursor 和 Windsurf 把 MCP server 的安裝做成一鍵設定。開發者不用搞配置檔，不用手動啟動 server process。這讓 MCP 從「有趣的開源專案」變成「我的 IDE 裡內建的功能」。

下載量從 10 萬跳到 800 萬。

第二個轉折：OpenAI 加入。 2025 年中，OpenAI 宣布 ChatGPT 和 Codex 原生支援 MCP。Google 的 Gemini 跟進。Microsoft Copilot 跟進。

當你的競爭對手都支援同一個協議，你不支援就是跟整個生態系切割。MCP 從 Anthropic 的專案變成產業共識。

第三個轉折：捐給 Linux Foundation。 2026 年初，Anthropic 把 MCP 捐給新成立的 Agentic AI Foundation（AAIF），共同創辦者包括 Anthropic、Block、OpenAI，支持者包括 Google、Microsoft、AWS、Cloudflare、Bloomberg。

這一步很關鍵。一個由單一公司控制的協議，其他公司會擔心路線圖被對手主導。捐給中立基金會之後，這個顧慮消失了。

生態系的規模

截至 2026 年 3 月：

10,000+ 個公開 MCP server，涵蓋開發工具、企業系統、資料庫、雲端服務
SDK 支援 4 種語言：Python、TypeScript、C#、Java
官方 server 覆蓋主流場景：GitHub、Google Drive、Slack、PostgreSQL、Puppeteer、Filesystem

社群 server 更瘋狂：Jira、Linear、Asana、AWS、GCP、Azure、Datadog、Sentry、Docker、Kubernetes⋯⋯你能想到的 SaaS 工具，幾乎都有人寫了 MCP server。

對開發者來說，這代表什麼？你不用再為每個 AI 應用重新寫整合邏輯了。寫一個 MCP server，Cursor 能用、ChatGPT 能用、Claude 能用、Gemini 能用。

我寫了一個 MCP server 之後的感想

體驗比我預期的簡單。用 Python 的 FastMCP 框架，核心程式碼不到 50 行就能把一個 REST API 包成 MCP server。

from fastmcp import FastMCP

mcp = FastMCP("my-api-server")

@mcp.tool()
async def get_user(user_id: str) -> dict:
    """根據 ID 取得使用者資料"""
    # 你的 API 呼叫邏輯
    response = await http_client.get(f"/api/users/{user_id}")
    return response.json()

@mcp.tool()
async def search_tickets(query: str, status: str = "open") -> list:
    """搜尋工單"""
    response = await http_client.get(
        "/api/tickets",
        params={"q": query, "status": status}
    )
    return response.json()

LLM 會自動讀取 tool 的名稱、參數型別和 docstring，決定什麼時候呼叫哪個工具。你不需要寫 prompt engineering 來教 AI 怎麼用你的 API。

真正花時間的是 權限控制和錯誤處理。MCP 協議本身不處理認證——這是設計決策，不是疏忽。每個 server 自己決定怎麼驗證身份、怎麼限制存取範圍。

我認為這是正確的。一個試圖解決所有問題的協議，最後什麼問題都解決不好。MCP 專注在「標準化 LLM 和工具之間的溝通格式」這一件事，做好它。

值得注意的風險

970 倍成長很漂亮，但有幾件事開發者應該留意。

安全性還在早期。 MCP server 本質上是讓 AI 操作你的系統。一個寫得不好的 server，可能讓 LLM 在你的資料庫上執行任意 SQL。2025 年底已經出現幾起 prompt injection 透過 MCP server 外洩敏感資料的案例。

如果你要部署 MCP server 到生產環境，最小權限原則不是建議，是必要條件。每個 tool 只暴露它需要的最少功能，輸入一律做驗證。

協議演進速度快。 MCP 的規格從 2024-11-05 版到現在已經改了好幾版。如果你在半年前寫的 server，可能需要更新才能跟最新的 client 相容。這是新標準的常態，但部署前記得確認版本。

vendor lock-in 風險轉移了，不是消失了。 以前是 lock-in 在特定 LLM 的 function calling 格式。現在 MCP 是通用的，但很多 server 實作綁定了特定的 hosting 方式（比如 Cursor 的本地 stdio 模式 vs. remote HTTP 模式）。

對開發者的實際影響

如果你在做 AI 相關開發，MCP 值得現在就學。不是因為炒作，是因為它解決了一個真實的問題，而且整個產業已經選邊站了。

三個可以立刻做的事：

挑一個你常用的內部 API，寫一個 MCP server。 50 行左右就夠。體驗一次從零到可用的過程，比讀十篇教學文有用。
在 Cursor 或 Claude Code 裡啟用幾個社群 server。 GitHub、filesystem、PostgreSQL 是好的起點。感受一下 AI 直接操作你的開發工具是什麼體驗。
讀一遍 MCP 的安全最佳實踐。 官方文件在 modelcontextprotocol.io 上有。在把 MCP 用到生產環境之前，先搞清楚攻擊面在哪裡。