Model Context Protocol (MCP) explained for beginners

模型與工具的整合向來是AI開發的痛點所在。傳統API設計給人類編寫的程式，這些程式通常知道自己確切需要什麼，能發出精確且確定的請求。但語言模型工作邏輯截然不同——它機率性地生成文本，面對不確定的輸入時需要推理、提問與探索，往往不知道該做什麼。這場不匹配催生了Model Context Protocol。

MCP的核心想法很簡潔：定義Client和Server兩方的通訊方式。Client通常是語言模型或代理系統（如Claude、Gemini），Server是暴露資源的環境（資料庫、檔案系統、公司內部工具）。當Client連接到Server時，Server不只被動回應資料，而是主動廣告自己的能力——能做什麼、有什麼資源、需要什麼輸入。這樣模型就能動態發現這些資源，無需開發者事先硬編碼每個API或endpoint。兩方之間的溝通透過簡單且明確的schema進行，Client發送「列出可用資源」、「執行此動作」、「擷取此資料」的請求，Server以結構化JSON回應。

MCP的設計將資源分為四層：Tools是模型可調用的動作（例如搜尋資料庫、發送郵件、分析檔案），Resources是資料與狀態（文檔、資料庫行、圖片），Prompts是可重用的行為模板，Context是外部資訊（聊天紀錄、公司資料、使用者偏好）。每個資源都附帶元數據描述其功能與預期輸入輸出，這使得模型能夠智慧地互動。關鍵在於協議跨所有工具強制一致的schema——無論模型使用GitHub server、CRM server或行事曆server，它說的都是同一種語言。

既然已有API，為何還需MCP？答案在於消費者的身分。API為人類編寫的程式設計，MCP為進行類人推理的模型設計。你可以把MCP看作API之上的抽象層。底層的MCP server可能仍在呼叫現有的REST或GraphQL API，但模型永遠看不見。它只透過結構化MCP schema互動，由協議統一處理發現、驗證與執行。這就是MCP的力量所在。

以實際應用為例，假設你要建一個個人助理代理，能檢查日曆、拉取會議記錄、起草追蹤郵件。舊方式得整合Google Calendar、Notion、Gmail API，為每個服務寫程式碼、處理認證與速率限制，教模型如何透過冗長脆弱的系統提示使用這些endpoint。新方式只需為各系統建立或安裝MCP server——日曆server、筆記server、郵件server。每個server廣告自己的功能，模型自動看到可用工具如「列出事件」、「取得會議摘要」、「發送郵件」，可推理使用順序與資料流。開發者無需為每個新工具寫膠水代碼，因為協議本身就確保一致性。

這場轉變已在進行。如同HTTP統一了網際網路，MCP正開始統一模型與工具的通訊方式。對開發者而言，現在學習MCP至關重要，因為在不久的將來，每個認真的AI開發者都需要知道如何讓自己的系統MCP-aware。