This is an openly attributed external skill from Anthropic. Source: https://github.com/anthropics/skills
This skill requires an environment with terminal, file and web access, such as Claude Code, because it researches, implements and tests a complete MCP server. Copy the guide below into your own skill environment if you want to set up this skill yourself. It describes the approach, architecture decisions and quality criteria; the environment additionally needs the original's referenced supplementary files (language-specific implementation guides, best-practice reference, evaluation guide). As a file: mcp-builder.en.json
# ROLE
You build MCP servers (Model Context Protocol) that let language models interact with external services through well-designed tools. The quality of an MCP server is measured by how reliably it helps a model solve real tasks.
# PHASE 1: RESEARCH AND PLANNING
## Understand modern MCP design
Weigh comprehensive API coverage against specialized workflow tools. Workflow tools are more convenient for individual tasks, comprehensive coverage gives agents more freedom to combine operations themselves. When in doubt, prioritize comprehensive API coverage.
Give tools clear, descriptive names with consistent prefixes (for example github_create_issue, github_list_repos) and action-oriented naming.
Keep tool descriptions concise and provide filtering and pagination so agents get focused, relevant data.
Phrase error messages so they guide the agent toward a solution with concrete suggestions.
## Study the MCP specification and framework documentation
Use the sitemap at https://modelcontextprotocol.io/sitemap.xml to find relevant pages, and fetch individual pages with the .md extension in markdown format. Check in particular the architecture overview, the transport mechanisms (Streamable HTTP, stdio) and the tool, resource and prompt definitions.
Recommended stack: TypeScript for servers (good SDK support, broad compatibility, models generate reliable TypeScript code), Streamable HTTP with stateless JSON for remote servers, stdio for local servers.
Load the SDK documentation for the chosen language (TypeScript or Python) along with the corresponding language-specific implementation guides before you start implementing.
## Plan the implementation
Understand the target API: core endpoints, authentication, data models. Prioritize comprehensive API coverage and list the most common operations first.
# PHASE 2: IMPLEMENTATION
## Set up the project structure
Set up the project structure according to the language-specific guide (package or module structure, dependencies, configuration files).
## Core infrastructure
Build shared building blocks: an API client with authentication, error handling, response formatting (JSON or markdown) and pagination support.
## Implement the tools
For every tool:
- Input schema with Zod (TypeScript) or Pydantic (Python), with constraints, clear descriptions and examples.
- Output schema where possible, for structured data.
- A concise function description with parameters and return type.
- Asynchronous processing for I/O operations, clean error handling with concrete hints, pagination where applicable.
- Annotations: readOnlyHint, destructiveHint, idempotentHint, openWorldHint.
# PHASE 3: REVIEW AND TEST
Check the code for duplication, consistent error handling, complete typing and clear tool descriptions.
TypeScript: verify the build with npm run build, test with the MCP Inspector (npx @modelcontextprotocol/inspector).
Python: check syntax with python -m py_compile, also test with the MCP Inspector.
# PHASE 4: CREATE EVALUATIONS
Create ten evaluation questions to check whether a language model can use the server productively.
Approach: review the tools, explore the available data with read-only operations, formulate ten complex, realistic questions, solve each question yourself and verify the answer.
Every question must be answerable independently of the other questions, require only read-only operations, require multiple tool calls and real exploration, be based on a real use case, have a single answer verifiable by text comparison, and be stable over time.
Format as an XML file:
```xml
<evaluation>
<qa_pair>
<question>...</question>
<answer>...</answer>
</qa_pair>
</evaluation>
```
# REFERENCE FILES FROM THE ORIGINAL
The original bundles supplementary files that a complete environment additionally needs: a best-practice reference on naming conventions, response formats, pagination, transport choice, security and error handling; a TypeScript implementation guide; a Python implementation guide; and an evaluation guide with question format and examples.
# DEFINITION OF DONE
[ ] Consulted the MCP specification and the SDK documentation for the chosen language
[ ] Tool names are consistent and action-oriented
[ ] Input schema and, where possible, output schema defined for every tool
[ ] Error handling is consistent throughout and gives concrete hints
[ ] Annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) set
[ ] Build or syntax check succeeded, test run with the MCP Inspector completed
[ ] Ten verified, realistic evaluation questions documented as XML
# DEPENDENCIES
Terminal and file access, access to the MCP specification and the SDK documentation (TypeScript or Python), the MCP Inspector for testing.
