MCP 與 API 比較：AI 工具何時用 MCP 或 HTTP

將 AI agent 連接到外部工具和 API 時，大致有兩種做法：使用 Model Context Protocol (MCP) 作為抽象層，或透過 HTTP 直接呼叫 API。兩者都可行，但在彈性、複雜度、效能和可攜性上有不同取捨。

本文以具體程式碼範例、延遲分析和決策框架比較這兩種做法，協助你選擇適合的方案。

兩種做法

直接 HTTP 整合

AI 應用程式（或其後端）使用標準 HTTP 請求直接呼叫外部 API。開發者撰寫程式碼來建立請求、處理驗證、解析回應，並將結果回傳給 LLM。

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

MCP 整合

AI 應用程式連接到包裝外部 API 的 MCP 伺服器。應用程式使用 MCP 協定探索可用工具、依名稱呼叫工具並接收結果。MCP 伺服器負責實際對外部 API 發出的 HTTP 呼叫。

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

關鍵差異在於：使用直接 HTTP 時，AI 應用程式擁有 API 整合程式碼。使用 MCP 時，MCP 伺服器擁有這些程式碼，而 AI 應用程式只需依名稱呼叫工具。

你也可以不自行建置伺服器，就擁有此圖中的 MCP 端：Quickchat AI 會為每個 AI Agent 託管一個 streamable-HTTP MCP 伺服器，而將你的 agent 轉換成 MCP 伺服器只需要將一個 URL 貼到 AI app 中。

程式碼比較

以下以實務範例比較兩種做法：取得 GitHub 使用者的 repositories。

直接 HTTP 整合

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """取得 GitHub 使用者的 repositories。"""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

若要將這段程式與 LLM 整合，你還需要：

• 以 LLM 所需格式撰寫工具定義（OpenAI function calling schema、Claude tool use schema 等）
• 撰寫程式碼解析 LLM 的工具呼叫、呼叫 get_user_repos，並將結果注入回對話
• 針對 HTTP 失敗、速率限制和驗證到期進行錯誤處理

MCP 伺服器

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """取得 GitHub 使用者最近更新的 10 個 repositories。

    Args:
        username: 要查詢的 GitHub username
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "未知"
            lines.append(f"- {r['name']} ({lang}, {stars} stars): {r['description'] or '無描述'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

MCP 版本會將 API 呼叫、驗證和回應格式化封裝在伺服器內。任何相容 MCP 的 client 都可以使用此工具，而不需要知道 GitHub API 的任何細節。

AI 應用程式的差異

效能比較

MCP 會在 AI 應用程式與外部 API 之間新增一層。這一層有成本。

延遲

對於 stdio transport（本機 MCP 伺服器），額外開銷很低：啟動時產生行程（一次性，通常低於 100ms），以及每則訊息的行程間通訊（在現代系統中低於 1 毫秒）。實務上，外部 API 呼叫會主導總延遲。

對於 遠端 MCP 伺服器（Streamable HTTP 或 SSE），你會在 client 與 MCP 伺服器之間多一次 HTTP 往返，再加上 MCP 伺服器到外部 API 的 HTTP 往返。如果 MCP 伺服器與外部 API 位於同一地點，此額外開銷很小（個位數毫秒）。如果它們位於不同區域，延遲會疊加。不過，使用者很少實際感受到 transport 的影響：在使用 Notion 託管的 MCP 伺服器建置說明中心 agent時，248 次工具呼叫平均每次 2.7 秒，其中幾乎全是 Notion 搜尋與頁面轉譯，而不是中間這一跳。

對多數 AI agent 使用情境而言，LLM 推論需要 500ms-5s，MCP 的額外開銷可忽略。

連線管理

直接 HTTP：你的應用程式會管理與每個外部 API 的連線。這表示要針對每個 API 處理連線池、重試邏輯和速率限制。

MCP：你的應用程式會為每個 MCP 伺服器管理一個連線。伺服器管理外部 API 連線。如果你有 10 個工具分散在 3 個 MCP 伺服器上，你只需管理 3 個連線，而不是 10 個。

何時使用 MCP

多個工具整合

如果你的 AI 應用程式需要連接 5 個以上的外部服務，MCP 可以降低整合負擔。你不必為每個服務撰寫並維護自訂 API client，而是連接到 MCP 伺服器（其中許多已作為開源專案提供）。

跨 AI 平台的可攜性

如果你為工具建置 MCP 伺服器，這些伺服器可與任何 MCP client 搭配使用：Claude Desktop、Cursor、Windsurf、自訂應用程式，以及 Quickchat AI 這類平台。若使用直接 HTTP，你需要針對每個平台的格式重新實作工具定義。

動態工具探索

MCP 透過 tools/list 支援執行階段工具探索。AI 應用程式可以連接到伺服器，並在沒有任何硬編碼設定的情況下了解有哪些工具可用。這適合工具經常變更或可由使用者設定的情境。

關注點分離

如果不同團隊負責不同工具，MCP 提供清楚的邊界。負責 Salesforce 整合的團隊建置並維護 Salesforce MCP 伺服器。AI 應用程式團隊連接到該伺服器，不需要理解 Salesforce 的 API。Salesforce API 的更新會在 MCP 伺服器中處理，而不需修改 AI 應用程式。

何時使用直接 HTTP

一個或兩個整合

如果你的 AI agent 只需要呼叫一個 API（例如資料庫查詢），執行 MCP 伺服器的額外開銷並不必要。直接 HTTP 呼叫更簡單，移動元件也更少。

你也不需要手動撰寫請求。plain-English API Action builder 會讀取已有文件的 REST API，產生方法、URL、參數和描述，然後讓你在啟用前測試真實回應。

對請求有最大控制權

MCP 伺服器會抽象化 HTTP 細節。如果你需要精準控制請求建構（特定 headers、查詢參數、請求簽署或非標準驗證），直接 HTTP 可讓你取得這種控制權，而不必與抽象層衝突。

對延遲敏感的操作

如果每一毫秒都很重要（例如即時語音 agent，其中工具呼叫必須在嚴格時間預算內完成），移除 MCP 層可省下一跳。

非 AI HTTP 呼叫

如果 HTTP 呼叫不是由 AI agent 觸發（例如同步資料的後端 cron job），MCP 就不相關。MCP 是專為 AI 對工具通訊設計。一般後端服務應使用一般 HTTP client。

混合做法

許多 production 系統同時使用兩者。模式如下：

• MCP 用於 AI agent 在對話中呼叫的工具整合（CRM 查詢、ticket 建立、Knowledge Base 查詢）
• 直接 HTTP 用於內部後端作業、webhooks 和系統對系統通訊

這也是 Quickchat AI 內部的運作方式。平台同時支援 HTTP Request Actions（具參數模板的直接 API 呼叫）和 Remote MCP Actions（連接到外部 MCP 伺服器）。你可為每個整合選擇合適做法：

如需了解此機制在實務上的詳細比較，包括 OpenAI 的 GPT Actions 與 MCP 的差異，請參閱 GPT Actions vs MCP。

決策框架

使用以下流程選擇：

1. AI agent 是否在呼叫工具？ 如果否（它是後端作業），使用直接 HTTP。
2. 你需要多少外部工具？ 如果是 1-2 個，直接 HTTP 較簡單。如果是 3 個以上，考慮 MCP。
3. 該服務是否已有預先建置的 MCP 伺服器？ 如果有，使用它可節省開發時間。
4. 你是否需要整合可跨多個 AI 平台運作？ 如果是，MCP 提供可攜性。
5. 延遲是否關鍵（工具呼叫預算低於 100ms）？ 如果是，對 MCP 額外開銷進行 benchmark 後再決定。
6. 不同團隊是否負責不同整合？ 如果是，MCP 的每個整合一個伺服器模型有助於劃分所有權邊界。

實務上，如果你正在建置需要與外部服務互動的 AI agent，MCP 越來越常成為預設選擇。預先建置伺服器的生態系已足夠龐大，你通常完全不需要撰寫任何伺服器程式碼就能開始。

延伸閱讀

• 將你的 AI Agent 連接到遠端 MCP 伺服器：逐步為你的 agent 提供即時工具
• Model Context Protocol 如何運作，MCP 說明：MCP 簡介
• GPT Actions vs MCP：與 OpenAI 做法的比較
• MCP Specification：官方協定規格
• HubSpot AI Actions：基於 HTTP 的 AI actions 實務範例
• OpenAI Hugging Face 事件，實際發生了什麼：逐步解析事件，以及 hacking 的真正含義