Build an MCP Server LLMs Can Actually Use, with Anthropic's mcp-builder

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

[ Log in to see the full prompt ]

## What is it, and what problem does it solve? MCP (Model Context Protocol) is an open protocol that lets LLMs operate external services (your API, database, SaaS) through "tools." But many people write MCP servers by mechanically wrapping each REST API endpoint into its own tool one-to-one, and the result is an agent that can't use it smoothly — tool names are inconsistent, parameters are unclear, error messages just throw a bare 500, and multi-step tasks have no matching tool. This is exactly the pain point mcp-builder solves: it uses an official four-phase process that forces you to design tools by working backward from "what real task does the LLM need to accomplish," rather than forward from the API docs. ## Why this source is worth using This is a first-party skill from Anthropic's official `anthropics/skills` repo — effectively a build guide written by the inventor of the MCP protocol itself. The official frontmatter describes it as: "Guide for creating high-quality MCP servers that enable LLMs to interact with external services through well-designed tools." Its core insight cuts to the heart of the matter: "The quality of an MCP server is determined by its ability to let LLMs complete real tasks." The repo includes four in-depth reference documents worth reading: `mcp_best_practices.md`, `python_mcp_server.md`, `node_mcp_server.md`, and `evaluation.md`, covering best practices, implementation in both languages, and evaluation methodology respectively. ## How to use it (four-phase overview) 1. Research and planning: read the MCP spec and framework docs, inventory the target API endpoints, and prioritize them by "contribution to real tasks" — endpoints that should be merged into a single workflow tool shouldn't be split into a pile of bare endpoints. 2. Implementation: build shared foundations first (API client, error handling, response formatting), then implement tools one by one. Define input/output schemas with Zod (TS) or Pydantic (Python); name tools with a consistent prefix plus action-oriented naming; error messages should "give a concrete next step" rather than just reporting failure; tag hints like readOnly/destructive/idempotent/openWorld appropriately. 3. Review and testing: run compilation checks and test each tool individually with the MCP Inspector. 4. Writing evals: design real-task questions that are "independent, read-only, require multiple tool calls, have a single verifiable answer, and don't drift over time," output them as `<qa_pair>` XML, and verify that an LLM can actually complete the task using this server. ## When to use it - You want to wrap an internal company API or some SaaS into MCP tools that Claude or another LLM can call. - You already have an MCP server, but agents keep using the wrong tool, get stuck on error messages, or can't complete multi-step tasks. - You want to validate server quality objectively with "real-task evals" instead of going by gut feel. ## Choosing a language Python uses the FastMCP SDK; Node/TypeScript uses the official MCP SDK (the official rationale: high SDK quality and broad compatibility across most runtime environments). Source: anthropics/skills (by Anthropic, Apache-2.0 license) — this entry is an edited adaptation with rewritten content; see the link above for the original.