用官方 mcp-builder 蓋一台「LLM 真的用得動」的 MCP server

MCP server 的好壞，不是看你包了幾個 API，而是看 LLM 能不能靠它完成真實任務。官方 mcp-builder 用四階段流程帶你把服務包成『代理用得動』的工具——含工具命名規範、Zod/Pydantic schema、會引導解法的錯誤訊息與真實評測。

[ Log in to see the full prompt ]

## 這是什麼？解決什麼痛點 MCP（Model Context Protocol）是讓 LLM 透過『工具』去操作外部服務（你的 API、資料庫、SaaS）的開放協定。但很多人把 MCP server 寫成『把 REST API 一個端點對一個工具機械式包裝』，結果代理根本用不順——工具命名混亂、參數不清、錯誤訊息只丟一句 500、需要好幾步的任務沒有對應工具。mcp-builder 解的就是這個痛點：它用官方四階段流程，逼你從『LLM 要完成什麼真實任務』反推工具設計，而不是從 API 文件正向硬包。 ## 為什麼值得用這個來源 這是 Anthropic 官方 `anthropics/skills` repo 的第一方技能，等於是 MCP 協定『發明方』自己寫的建置指南。官方 frontmatter 描述為：「Guide for creating high-quality MCP servers that enable LLMs to interact with external services through well-designed tools.」它的核心金句點破整件事的本質：『MCP server 的品質，由它讓 LLM 完成真實任務的能力決定。』repo 內附四份可深讀的參考文件：`mcp_best_practices.md`、`python_mcp_server.md`、`node_mcp_server.md`、`evaluation.md`，分別涵蓋最佳實務、兩種語言實作與評測方法。 ## 怎麼用（四階段要點） 1. 研究規劃：讀 MCP 規格與框架文件，盤點目標 API 端點，依『對真實任務的貢獻』排序——該合併成工作流工具的就別拆成一堆裸端點。 2. 實作：先建共用基礎（API client、錯誤處理、回應格式化），再逐工具實作。輸入輸出用 Zod(TS)/Pydantic(Python) 定 schema；工具用一致前綴 + 動作導向命名；錯誤訊息要『給出具體下一步建議』而非乾報錯；標好 readOnly/destructive/idempotent/openWorld 等 hint。 3. 審查測試：跑編譯檢查、用 MCP Inspector 逐工具實測。 4. 寫評測：設計『獨立、唯讀、需多步工具呼叫、答案單一可驗證、不隨時間漂移』的真實任務題，用 `<qa_pair>` XML 輸出，驗證 LLM 真的能靠這台 server 把事做完。 ## 何時用 - 你要把公司內部 API 或某個 SaaS 包成 Claude / 其他 LLM 能調用的 MCP 工具。 - 你已經有一台 MCP server，但代理常用錯工具、卡在錯誤訊息、或多步任務做不完。 - 你想用『真實任務評測』來客觀驗收 server 品質，而非憑感覺。 ## 語言選擇 Python 走 FastMCP SDK；Node/TypeScript 走官方 MCP SDK（官方理由：SDK 品質高、在多數執行環境相容性好）。 📎 來源：anthropics/skills（作者 Anthropic，Apache-2.0 授權）— 本篇為繁中改寫整理，內容經改寫，原始內容見上方連結。