張文鈿：淺談模型上下文協定MCP應用開發

1. 一句話總結

MCP 把「大模型如何取得工具與資料」這件事標準化，讓工具廠商只要寫一次 server，所有支援 MCP 的 client（Claude、Cursor、ChatWise……）都能直接使用，但講者也很老實地指出，remote 部署與身分驗證這兩塊在今年五月這個時間點仍然非常不成熟。

2. 重點筆記

講者張文鈿，網路暱稱 ihower，2002 年起投入 Web 軟體開發，專長是 Ruby on Rails 的全端開發；2018 年自行創業成立愛好資訊科技有限公司（aihao.tw），2023 年起全力投入 AI 工程領域，經營「愛好 AI Engineer」電子報，並開設招牌課程「LLM 應用開發工作坊」（查證後，公司與電子報全名以 ihower.tw/blog/about 的自我介紹為準）。講者本人也把這場的完整投影片和文章公開發表在自己的部落格上（文章、投影片 PDF），是這篇筆記最直接的外部佐證來源。

為什麼需要 MCP

• LLM-based Agent 的定義：用大模型做決策的 AI 元件，依照目標指令決定步驟、不斷呼叫工具，直到完成任務。講者的比喻是「大模型本身就像一位被關在房間裡的天才」，沒辦法主動學習或操作世界，必須靠外部工具存取即時資訊、操作電腦。
• 技術上看，Agent 就是「LLM 在迴圈裡不斷使用工具」：程式維護一份 instructions / tools / messages，每輪呼叫模型，模型若要求呼叫工具就執行工具、把結果塞回 messages，直到模型不再要求呼叫工具、直接回覆最終答案為止。這個 tool 呼叫在 API 層面就是所謂的 function calling。
• 講者提到，function calling 從前年就有了，但當時一次對話大概只呼叫一兩次工具；到了最近，像 OpenAI o3 這類模型已經可以連續呼叫工具到數百次（講者自述，無外部來源佐證，原話是「照他們的說法」）。
• 核心論點：「大模型的原始智力不等於智慧軟體系統」，模型的智力只是基石，要轉換成真正有用的系統還需要兩個關鍵：工具整合（讓模型能實際操作、查資料、記憶與回應）、正確的上下文（依任務動態提供模型需要的資訊）。這整套動態管理的做法就是「Context Engineering」。
• MCP（Model Context Protocol）是 Anthropic 去年底開源的標準化協議，定義模型如何取得 context，範圍包括 Tools、Resources、Prompts 三種原語。官方規格站：modelcontextprotocol.io。

MCP 的角色分工：client app 與 server

• 常見使用場景：讓 app 能更方便地安裝第三方工具擴充。Client app 包含本機的 Claude Desktop、ChatWise、Cursor、Windsurf 等 GUI 應用與編輯器；雲端的 Claude Web、Dify 等服務；以及自己開發的 Agent 程式（官方 client 清單：modelcontextprotocol.io/clients）。
• 關鍵特性：MCP 是「以場景和使用案例為中心」而非單一 function，安裝一個 MCP server 通常就是一次裝進一整包工具。舉例，Slack MCP server 一次會裝入八個 function：slack_list_channels、slack_post_message、slack_reply_to_thread、slack_add_reaction、slack_get_channel_history、slack_get_thread_replies、slack_get_users、slack_get_user_profile。
• Before MCP：針對每個外部廠商（例如 Slack、GitHub）都得自己寫 function schema 與實作，全部是 app 開發者的責任。
• After MCP（啟動時）：MCP client 在 app 啟動時透過標準操作 list_tools() 向 server 詢問可用工具，取得 function schema 後插入 Agent 定義。
• After MCP（執行時）：模型根據 function schema 挑選工具，client 透過標準操作 call_tool(function_name) 執行工具。責任因此區隔開：MCP server 變成工具廠商的責任，包含 schema 與實作本身。
• 標準化帶來的好處：對 app 開發者來說，銜接任何 MCP server 都很簡單；對工具廠商來說，寫一次 server 就能被所有 MCP client 使用；對用戶來說，app 具備任意擴充能力；對企業來說，能清楚切開「負責 Agent 的團隊」與「負責 Tool 的團隊」，各自分工。講者引用 a16z 的觀察，指出 MCP 生態系自去年底以來成長非常快（a16z 文章）。

MCP server 提供的三種 context

• Tools：提供 function 給模型使用，實務上就是用 function calling 運作，官方 Python SDK 只要寫一個函式加上 @mcp.tool() decorator 就能做出一個 MCP server（python-sdk）。
• Resources：提供資料給 client app，行為類似 HTTP GET，讓 app 主動索取資料；用途完全看 client app 怎麼設計（例如 Claude Desktop 是一個選單，選了之後插入 prompt）。講者特別解釋「為什麼不直接用工具提供資料」：Tool 是設計給模型用的，Resources 是設計給 client app 用的，用途和整合方式不同。
• Prompts：提供事先設計好的高品質 prompt 樣板讓 client app 挑選使用，例如複雜任務或高品質提問場景（資料分析、摘要生成等）。介面全看 client app：Claude App 是下拉選單、跳出表單讓你填參數；Zed IDE 則是在對話中用 // 快捷鍵挑選樣板。
• 講者的實務評價很直白：「實際上只有 Tools 最好用，另外兩個我是覺得還好，主要還是要看 client app 是如何使用的。」也強調「MCP 的精神不只是提供模型的 context，而是設計一個給整個 client app 應用的標準協議」。

Transport：三種傳輸實作

MCP client 與 server 之間的訊息本身用 JSON-RPC 定義（schema.ts），目前有三種實作：

• ① 本機 stdio（標準輸入輸出）：app 啟動時依設定把 MCP server 跑成一個 child process，透過標準輸入輸出跟主程式溝通。這是目前絕大多數 MCP server 的做法，優點是系統資源耗費少、不用煩惱 HTTP server 佔用 port；缺點是需要本機環境能正確執行那支程式（通常是 JavaScript 或 Python），非開發者常常因此裝不起來。
• ② 遠端 HTTP+SSE（2024-11-05 版規格）：MCP server 是一個獨立的 HTTP server，維持一條持續連線，有兩個端點：SSE endpoint（接收 server 事件）與 HTTP POST endpoint（送出訊息）。持續連線對後端部署與伺服器要求都比較高。
• ③ 遠端 Streamable HTTP（2025-03-26 版規格，取代 SSE）：可以是 stateless 也可以是 stateful，不必維持持續連線，只有一個端點（通常是 /mcp），依 client 端的 HTTP header（Accept: application/json 或 text/event-stream）決定回應方式。官方建議往這個新標準逐步靠攏。
• 除錯工具：MCP Inspector（GitHub），一個通用 client app，指令 npx @modelcontextprotocol/inspector 就能啟動，填入 server 的啟動指令（例如 npx @modelcontextprotocol/server-everything）按下 Connect，就能檢視有哪些 tools、resources、prompts。

推薦的 MCP servers 與 client 開發

• 官方範例：everything、filesystem（僅限指定目錄）、fetch、slack。
• 推薦清單：DesktopCommanderMCP、sequential-thinking；瀏覽器相關的 playwright-mcp、browserbase（SaaS）；搜尋相關的 tavily-mcp（SaaS）、firecrawl-mcp-server（SaaS）；程式碼執行環境 e2b（SaaS）與 pydantic run-python（免費）。
• Client 開發推薦官方 Python SDK，Gemini API 文件也有 function calling 搭配 MCP 的範例。講者個人推薦 OpenAI Agents SDK，宣告 Agent 時只要把 mcp_servers=[...] 參數帶進去，工具就會自動展開，他形容這個寫法「非常讚」。他自己的兩個示範程式：用 filesystem MCP server 管理目錄、用 tavily 和 filesystem MCP server 做搜尋並存成 csv 檔案（example1、example2）。

Remote MCP 踩坑經驗

講者用「踩坑經驗」四個字形容這整塊，語氣明顯比前面介紹 MCP 概念時謹慎許多：

• MCP 只是一個 protocol，不代表廣泛可用：絕大部分各家 MCP server 目前仍是本機 stdio 版本；若第三方工具需要授權，得自己拿到工具廠商的 API key 寫進設定檔才會動。
• 少部分做了 remote MCP server 的廠商，也大多只做了 SSE 版本，還不是新的 Streamable HTTP。
• Client app 支援也不一致：本機版 Claude Desktop 不支援 remote；Claude Web 版支援安裝 SSE 版的 remote MCP server（需要買 Max Plan），但似乎還不支援 Streamable HTTP；有趣的是在 Web 版設定好 remote MCP server 之後，會自動同步到本機的 Claude app（講者說他也不確定這是怎麼設計的）。
• OpenAI Responses API 在講者上台的前一晚就搶先支援了 remote MCP server（官方文件）。
• Python SDK 到五月初才把 Streamable HTTP server 支援做好（v1.8.0，release 頁）。
• 如果 client 不支援 remote、但 server 是遠端的，可以用 Cloudflare 出的本機 proxy MCP server 繞過去：npm 套件 mcp-remote，搭配 Cloudflare 官方指南。

Remote MCP 的身分驗證：一團糟

講者原話：「目前 remote 的 auth 是一團糟。」

• 最簡單的 HTTP header bearer 做法，MCP Inspector 有支援，但 Python SDK 當時 server 端沒有實作（issue #431）。
• 規格從 2025-03-26 版開始支援 OAuth 2 認證（changelog）。
• Claude Web 支援 SSE 加 OAuth，但似乎不支援 Streamable HTTP；其他 client（例如 ChatWise）雖支援 SSE 和 Streamable HTTP，卻不支援 OAuth。
• Python SDK：server 端五月中旬才把 OAuth 做好（PR #255，附一個範例 simple-auth），client 端則是五月下旬才做好（PR #751）。
• MCP Inspector 0.12 版有 bug 跑不了 OAuth，得降級到 0.11 才能跑 SSE 版 OAuth；Streamable HTTP 搭配 OAuth 當時仍有 bug、不會跳轉授權（issue #390）。講者上台的前一天，0.13 版才把這些問題修好。
• OpenAI Responses API 能幫你把 HTTP auth header 傳過去，但不會幫你跑完整的 OAuth 流程。
• OAuth 2 規格本身當時也還在改（PR #338），講者引用了一篇部落格形容這個現況：The updated MCP OAuth spec is a mess。

Sampling、Roots 與多代理組合

• Sampling：MCP server 可以反過來請求 client 做一次 LLM 推論——server 送出 sampling/createMessage 請求，client 可以讓使用者審閱／修改 prompt（人工審核機制），執行推論後把結果回傳，server 再繼續後續工具流程。設計動機有兩個：讓 MCP server 本身不必具備大模型能力、可以沿用 client 端的模型；以及安全隱私考量——公司裝了某個 MCP server，但不希望它又跑去呼叫別人家的大模型，透過 Sampling 就能讓它沿用自己裝的那個 LLM。講者坦言這功能目前很少 app 或 library 真的實作。
• 補查：MCP 規格裡除了 Sampling，client 端還定義了另一個原語叫 Roots——讓 client 向 server 宣告可操作的檔案系統邊界（一組 file:// URI），server 可以請求 roots/list 取得清單，並在清單變動時收到通知；用途是限制 server 能存取的目錄範圍，例如專案或工作區選取器（這場沒有講到 Roots，此處依官方規格補上，roots 規格頁）。
• 複習 Agents as Tools：可以把一個 Agent 包裝成 function，當作另一個 Agent 的工具使用（OpenAI Agents SDK 支援，官方文件）。
• Agents as Tools + MCP 組合：Agent B、C 可以被包裝成 MCP server，安裝在 Agent A 上，讓 Agent A 能跟 B、C 遠端溝通——講者直接點名「這就是 Google A2A（Agent2Agent）Protocol 在做的事」，A2A 只是 MCP 的其中一種使用特例。
• 進一步組合：Agent B 可以同時是 Agent A 的 MCP server，又是 Agent X、Y 的 MCP client；如果再搭配 Sampling，整串架構的 LLM 推論需求都可以交給 Agent A 的模型處理。
• Demo：講者現場展示一個「跟 ihower 對話」的 MCP server，程式碼用 FastMCP 加 OpenAI Agents SDK，@mcp.tool() 包一個 talk_to_ihower(query, previous_response_id) function，內部跑一個以 gpt-4.1-mini 為模型、人設是「張文鈿 Wen-Tien Chang（ihower）」的 Agent，並以 mcp.run(transport="sse") 啟動。這個 remote MCP server 掛在 mcp.aihao.tw/sse，可以直接裝進 Claude 或 ChatWise，讓自己的 Agent 去訪談「ihower 分身」。若 client 不支援 remote（例如 Claude Desktop），一樣可以用前面提到的 Cloudflare mcp-remote proxy 繞過去。

業界速度：兩則就在那一兩天發生的消息

講者特別強調這個領域的變化速度：OpenAI Responses API 在他上台前一晚才剛加入 remote MCP server 支援；而 Anthropic API 的「MCP connector」則是在他上台前不到一天才宣布（官方文件）。他的原話是「這個世界真的是非常的捲」。OpenAI 加上這個支援後，官方模型可以直接呼叫 MCP server、不必再繞回開發者自己的 app，效率上有明顯改善。

安全性問題

• 安裝太多 MCP server／工具會造成 tool name 撞名衝突、也會拖累 LLM 表現；講者提到兩種解法方向：設計一種「搜尋工具的工具」（search tools 的 tool），或是逐層揭露（不要一次把所有 tools 都塞給 LLM，而是隨任務狀態動態調整）。
• 安全性風險三種：程式執行攻擊（多數 MCP server 透過本機 stdio 執行，若從不明來源安裝可能執行到惡意程式碼）、命名攻擊（用跟常見工具極相似的名稱冒充合法工具，騙取信任與執行機會）、MCP 工具中毒（把 prompt injection 藏在 tool description 裡）。
• 延伸閱讀（講者提供）：MCP: Flash in the Pan or Future Standard?、Everything Wrong with MCP、The "S" in MCP Stands for Security、Deep Dive MCP and A2A Attack Vectors for AI Agents。

Roadmap：Registry 與 Server Discovery

• MCP Registry：官方正在籌備一個統一的 metadata service，目標包括方便找到合適的 MCP server（server discoverability）、提供 API 讓未來的 Agent 能動態發現並自動安裝工具、建立信任與安全機制（這是誰建的 server、是不是官方發布的，降低裝到惡意 server 的風險）、版本追蹤（正在用哪個版本的 server）。非官方的類似服務目前已經有好幾個：mcp.so、mcp.composio.dev、smithery.ai、glama.ai/mcp/servers。
• Server Discovery：官方標準化一個 .well-known/mcp 檔案，用在第一方伺服器上。舉例：你跟 Agent 說「幫我管理我的 shopify.com 商店」，Agent 就去檢查 shopify.com 是否有 .well-known/mcp.json；如果有，Agent 就能發現 Shopify 官方的 MCP server 並自動安裝，接著就知道如何幫你管理商店——這就是讓 Agent 自動發現與安裝 MCP server 的具體做法。

推薦學習資源

講者最後推薦兩個資源：DeepLearning.AI 與 Anthropic 合作的短期課程 MCP: Build Rich-Context AI Apps with Anthropic，以及 Anthropic 的 Mahesh Murag 主講的完整工作坊影片 Building Agents with Model Context Protocol。

3. 關鍵數據與案例

• Slack MCP server 一次安裝八個 function（slack_list_channels 等，見上）。
• OpenAI o3 級模型號稱可連續呼叫工具達數百次（講者自述，無外部來源佐證）。
• Python SDK 時間線：五月初（v1.8.0）補上 Streamable HTTP server 支援；五月中旬 server 端 OAuth 完成（PR #255）；五月下旬 client 端 OAuth 完成（PR #751）。
• MCP Inspector：0.12 版 OAuth 有 bug，需降級到 0.11 才能跑 SSE 版 OAuth；講者上台前一天發布的 0.13 版才把這些 bug 修好。
• 業界速度案例：OpenAI Responses API 與 Anthropic API 的 MCP 相關支援，前後只差了不到一天就相繼發布。
• Demo 案例：talk_to_ihower 這個 MCP server 把「跟 ihower 對話」包裝成一個可安裝的工具，實際示範了 Agent-as-MCP-server 的組合方式。

4. 金句

• 「大模型本身就像一位被關在房間裡的天才，沒辦法主動學習或操作世界。」
• 「MCP 的精神不只是提供模型的 context，而是設計一個給整個 client app 應用的標準協議。」
• 「目前 remote 的 auth 是一團糟。」
• 「這個世界真的是非常的捲。」

5. 提到的工具與名詞

MCP（Model Context Protocol）、MCP server／client、Tools／Resources／Prompts、stdio、HTTP+SSE、Streamable HTTP、JSON-RPC、MCP Inspector、Python SDK、OpenAI Agents SDK、Gemini API、Claude Desktop／Claude Web、ChatWise、Cursor、Windsurf、Dify、Slack MCP server、filesystem／fetch／everything MCP server、DesktopCommanderMCP、sequential-thinking MCP、playwright-mcp、browserbase、tavily-mcp、firecrawl-mcp-server、e2b、pydantic run-python、OAuth 2.0、Sampling、Roots、Agents as Tools、Google A2A（Agent2Agent）Protocol、MCP Registry、.well-known/mcp、Context Engineering。

6. 延伸觀察

這場最值得記下來的是那張「Before／After MCP」的責任區隔圖：把工具 schema 和實作的責任從 app 開發者身上完全移到工具廠商身上，這件事聽起來簡單，但真的是讓「企業內部各部門自己維護自己的 MCP server、AI 團隊只管裝」這種分工變得可行，難怪講者說企業內部採用速度這麼快。

不過講者花了幾乎一半篇幅講 remote MCP 和 OAuth 的踩坑經驗，這對這個生態系的成熟度是一個很實際的註腳：一個協議規格存在，不代表整條路徑（stdio → SSE → Streamable HTTP，加上認證）都已經打通。像 MCP Inspector 一個小版本就修掉一批 OAuth bug、Anthropic 和 OpenAI 前後不到一天各自補上 remote 支援，以這種節奏來看，現階段要做 production 等級的 remote MCP 整合，還是得抓緊盯著各家 SDK 的更新頻率，而不是一次做完就放著。

Agent-as-MCP-server 搭配 Sampling 那段的延伸性最強：把多代理架構跟 MCP 疊在一起，本質上就重新推導出了 A2A 在做的事，這說明 MCP 不只是「工具協定」，更像是一個可以拿來搭建代理人網路的通用傳輸層。MCP Registry 和 .well-known/mcp 這兩個 roadmap 項目如果真的做出來，未來讓 Agent 自己去發現、驗證、安裝工具，應該會讓現在這種「每個 client 自己維護一份 MCP server 清單」的土法煉鋼方式徹底改觀。

7. 資料來源