MCP 協定教學｜Model Context Protocol AI Agent 工具整合

如果你有在關注 AI Agent 的發展，大概會注意到一個問題：每次要讓 LLM 連接新的工具或資料來源，就得重新寫一堆整合程式碼。不同的 API 格式、認證方式、回傳結構，光是維護這些連接器就夠頭痛了。MCP（Model Context Protocol）就是為了解決這個痛點而誕生的開放協定。

我自己在做 RAG 應用開發的過程中，深刻感受到工具整合的碎片化問題。這篇文章會帶你從零開始理解 MCP 的設計哲學，並且手把手用 Python 實作一個 MCP Server，讓你的 AI Agent 真正具備「隨插即用」的能力。

什麼是 MCP（Model Context Protocol）？

MCP 全名 Model Context Protocol，是由 Anthropic 在 2024 年底提出的開放標準協定。你可以把它想成「AI 世界的 USB-C」——就像 USB-C 統一了各種裝置的充電和傳輸介面，MCP 統一了 AI 模型與外部工具之間的溝通方式。

在 MCP 出現之前，每個 AI 應用要連接資料庫、呼叫 API、讀取檔案，都需要針對每個工具寫專屬的整合程式碼。這導致了 M×N 的問題：M 個 AI 應用要連接 N 個工具，就需要 M×N 個整合方案。MCP 把這個問題簡化成 M+N——每個 AI 應用只需要實作 MCP 客戶端，每個工具只需要實作 MCP 伺服器。

為什麼 MCP 對 AI Agent 至關重要？

老實說，2025 年以前的 AI Agent 大多停留在「概念驗證」階段，很大一部分原因就是工具整合太痛苦了。MCP 帶來了幾個根本性的改變：

標準化介面：所有工具遵循相同的協定格式，不再需要為每個 API 寫轉接層
動態發現：AI Agent 可以在執行時動態發現可用的工具，而不是在編譯時就寫死
安全隔離：MCP 的分層架構讓敏感資料（如資料庫密碼）留在 Server 端，LLM 永遠不會直接接觸到
生態系統：因為是開放標準，社群已經建立了大量現成的 MCP Server，從 GitHub、Slack 到各種資料庫都有

這對於正在學習 AI Agent 開發的人來說，MCP 大幅降低了入門門檻。

MCP 的核心架構：Host、Client、Server

MCP 的架構設計非常清晰，分成三個核心角色。理解這三個角色的關係，是掌握整個協定的關鍵。

Host（宿主）

Host 是使用者直接互動的應用程式，例如 Claude Desktop、VS Code 中的 AI 擴充套件，或是你自己開發的聊天介面。Host 負責管理一個或多個 MCP Client 的生命週期，同時也負責安全策略——決定哪些工具可以被呼叫、是否需要使用者確認等。

Client（客戶端）

每個 Client 負責與一個 MCP Server 建立一對一的連線。Client 的主要工作是協定協商（negotiation）——在連線建立時，Client 和 Server 會交換彼此支援的能力（capabilities），確保雙方能正確溝通。

Server（伺服器）

Server 是真正對接外部工具的地方。一個 MCP Server 可以暴露三種類型的功能：

Tools（工具）：LLM 可以主動呼叫的函式，例如查詢資料庫、發送郵件
Resources（資源）：類似 REST API 的資料端點，提供結構化的上下文資訊
Prompts（提示模板）：預先定義的互動模板，引導 LLM 以最佳方式使用工具

整個通訊基於 JSON-RPC 2.0，這意味著如果你寫過任何 JSON-RPC 的程式，上手 MCP 會非常快。

用 Python 打造你的第一個 MCP Server

理論講夠了，我們直接來寫 code。這個範例會建立一個簡單的天氣查詢 MCP Server。

環境準備

pip install mcp httpx

MCP 的 Python SDK 設計得相當簡潔。安裝完成後，你只需要幾十行程式碼就能建立一個功能完整的 Server。

實作 MCP Server

from mcp.server.fastmcp import FastMCP
import httpx

# 建立 MCP Server 實例
mcp_server = FastMCP("weather-server")

@mcp_server.tool()
async def get_weather(city: str) -> str:
    """查詢指定城市的目前天氣狀況"""
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"https://wttr.in/{city}?format=j1"
        )
        data = resp.json()
        current = data["current_condition"][0]
        desc = current["weatherDesc"][0]["value"]
        temp = current["temp_C"]
        feels = current["FeelsLikeC"]
        humidity = current["humidity"]
        return f"{city}: {desc}, {temp}C, feels {feels}C, {humidity}%"

@mcp_server.tool()
async def get_forecast(city: str, days: int = 3) -> str:
    """查詢未來幾天的天氣預報"""
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"https://wttr.in/{city}?format=j1"
        )
        data = resp.json()
        lines = []
        for day in data["weather"][:days]:
            desc = day["hourly"][4]["weatherDesc"][0]["value"]
            lines.append(f"{day['date']}: {desc}, {day['mintempC']}~{day['maxtempC']}C")
        return "\n".join(lines)

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

這段程式碼做了幾件事：用 FastMCP 建立一個名為 "weather-server" 的 MCP Server，然後用 @mcp_server.tool() 裝飾器註冊了兩個工具。注意 docstring 非常重要——MCP 會把它傳給 LLM，讓模型知道什麼時候該呼叫這個工具。

將 MCP Server 連接到 LLM

Server 寫好之後，要怎麼讓 Claude 或其他 LLM 使用它？以 Claude Desktop 為例，你只需要在設定檔中加入：

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["path/to/weather_server.py"]
    }
  }
}

重啟 Claude Desktop 後，你就能直接問「台北今天天氣如何？」，Claude 會自動呼叫你的 MCP Server 來取得即時天氣資料。如果你是用自己開發的 Agent 框架，也可以透過 MCP 的 Client SDK 來連接。這跟我們在 LangChain 與 LlamaIndex 的比較中討論的工具整合方式有很大的不同——MCP 讓整合變成一個標準化的流程。

MCP 真實應用場景

除了天氣查詢這種入門範例，MCP 在實際生產環境中已經有很多有趣的應用：

企業知識庫整合：讓 AI Agent 直接查詢公司內部的 Confluence、Notion 或自建知識庫，不需要預先把所有文件塞進 prompt
程式碼庫導航：GitHub MCP Server 讓 AI 可以搜尋 repo、讀取檔案、查看 PR，大幅提升程式開發效率
資料庫操作：透過 MCP 讓 AI Agent 安全地執行 SQL 查詢，Server 端可以做權限控管和 SQL 注入防護
工作流自動化：串接 Slack、Email、日曆等工具，打造真正能執行任務的 AI 助理

在 LangGraph 工作流教學中，我們介紹過 Agent 的任務編排。MCP 完美補足了其中「工具層」的標準化需求。

MCP 與 Function Calling 的差異

你可能會想：「MCP 跟 OpenAI 的 Function Calling 不是很像嗎？」表面上看確實類似，但本質上有幾個關鍵差異：

面向	Function Calling	MCP
標準化	各家 LLM 各有實作	開放標準，跨平台通用
執行位置	通常在應用程式端	獨立的 Server 進程
工具發現	需在 prompt 中定義	動態發現與協商
安全性	依賴應用層實作	協定層內建安全機制
可重用性	綁定特定應用	一次實作，處處可用

簡單來說，Function Calling 是「告訴 LLM 有哪些函式可以呼叫」，而 MCP 是「建立一個完整的工具生態系統」。兩者可以共存——事實上，很多 MCP Client 的底層就是透過 Function Calling 來觸發工具呼叫的。

結語：MCP 是 AI Agent 的未來基礎設施

MCP 解決的是 AI 應用開發中一個根本性的問題：工具整合的標準化。隨著越來越多的工具提供 MCP Server，AI Agent 的能力邊界會不斷擴展。

如果你正在建構 AI 應用，我強烈建議從現在開始擁抱 MCP。不管你是用 LangChain、LlamaIndex 還是自己的框架，MCP 都能作為底層的工具整合層。回到我們在 RAG 應用開發指南中提到的架構，MCP 就是讓「檢索」和「行動」兩個環節真正標準化的關鍵拼圖。

下一步，你可以到 MCP 的官方 GitHub 看看已經有哪些現成的 Server 可以使用，或者按照本文的範例，試著為你自己的 API 建立一個 MCP Server。一旦跨出第一步，你會發現整合新工具變得前所未有的簡單。

MCP 協定實戰教學：用 Model Context Protocol 打造可連接任意工具的 AI Agent