An MCP server (Model Context Protocol) is the bridge through which a language model can actually operate an external service, not just talk about it. The MCP Builder guides you through the four phases of this build: researching the protocol specification and the matching SDK documentation, implementing core infrastructure and individual tools with typed inputs and outputs, review and testing through the MCP Inspector, and creating ten realistic evaluation questions that show whether a model uses the server productively.
\nThe skill is built for developers who want to connect an external API or an internal service so that a language model can access it reliably, whether in TypeScript or in Python. It is especially useful when an API already exists and the real question is not whether to connect it, but how: tool scoping, naming conventions, error handling, pagination.
\nThe honest limit: this skill requires an environment with terminal, file and web access, such as Claude Code, because it actually writes, builds and tests code. It does not replace studying the MCP specification itself or knowing the target API, it only structures the path there. The environment needs the original's supplementary files on TypeScript, Python and evaluations in addition to this guide.
\n" }, { "id": "skill-text", "title": "Skill Text", "html": "This is an openly attributed external skill from Anthropic. Source: https://github.com/anthropics/skills
\nThis 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
\n" } ], "schritte": [ { "nr": 1, "titel": "Define target and language", "beschreibung": "The target API or target service, the desired programming language and the available API documentation are named.", "rolle": "mensch" }, { "nr": 2, "titel": "Research and planning", "beschreibung": "The MCP specification and SDK documentation are studied, and tool scoping, naming conventions and input and output schemas are defined.", "rolle": "automatisch" }, { "nr": 3, "titel": "Implementation", "beschreibung": "Core infrastructure such as the API client, error handling and pagination, along with the individual tools, are built.", "rolle": "automatisch" }, { "nr": 4, "titel": "Test and review", "beschreibung": "The build or syntax is checked, and the server is tested through the MCP Inspector.", "rolle": "automatisch" }, { "nr": 5, "titel": "Create evaluation questions", "beschreibung": "Ten realistic questions are formulated, solved, verified and documented as an XML file.", "rolle": "automatisch" }, { "nr": 6, "titel": "Approve the server", "beschreibung": "The finished server is reviewed and approved before it goes into production use.", "rolle": "freigabe" } ], "herausgeber": "Voyage Digital", "version": "2.0", "stand": "2026-07-26", "umsetzung": [ { "titel": "Choose the target service", "text": "Starting with a service that already has a documented API and is needed by the team in the near term works best." }, { "titel": "Fix language and transport", "text": "TypeScript with Streamable HTTP is the recommended default path for remote servers, stdio remains reserved for local servers." }, { "titel": "Use the skill in an agentic environment", "text": "The skill text is loaded into an environment with terminal, file and web access, such as Claude Code." }, { "titel": "Test and have the server approved", "text": "Before production use, the server is checked with the MCP Inspector and reviewed by a second person." }, { "titel": "Reuse the pattern for further services", "text": "Proven naming conventions and error handling are carried over to the next MCP server." } ], "zutaten": [ "Target API", "Programming language", "API documentation" ], "beispielSzenario": "A development team wants to make its internal ticketing system accessible to a language model so it can read, comment on and route open tickets. Building on the existing REST API, the MCP Builder produces a TypeScript based MCP server: descriptive tool names such as tickets_list and tickets_add_comment, typed inputs and outputs, error handling with concrete hints, and ten test questions that show the model reliably finds and processes open tickets.", "eingaben": [ { "feld": "Target API or target service that the MCP server should connect", "pflicht": true }, { "feld": "Programming language: TypeScript or Python (TypeScript recommended)", "pflicht": true }, { "feld": "API documentation or access to it", "pflicht": true }, { "feld": "Transport type: Streamable HTTP for remote servers, stdio for local servers", "pflicht": false }, { "feld": "Existing server code, if extending an existing implementation", "pflicht": false } ], "ausgabe": "A researched implementation concept, the complete server code with typed tools, error handling and pagination, a test routine through the MCP Inspector and ten evaluation questions to check whether a language model can use the server productively.", "prompt": "# ROLE\nYou 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.\n\n# PHASE 1: RESEARCH AND PLANNING\n\n## Understand modern MCP design\nWeigh 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.\n\nGive tools clear, descriptive names with consistent prefixes (for example github_create_issue, github_list_repos) and action-oriented naming.\n\nKeep tool descriptions concise and provide filtering and pagination so agents get focused, relevant data.\n\nPhrase error messages so they guide the agent toward a solution with concrete suggestions.\n\n## Study the MCP specification and framework documentation\nUse 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.\n\nRecommended 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.\n\nLoad the SDK documentation for the chosen language (TypeScript or Python) along with the corresponding language-specific implementation guides before you start implementing.\n\n## Plan the implementation\nUnderstand the target API: core endpoints, authentication, data models. Prioritize comprehensive API coverage and list the most common operations first.\n\n# PHASE 2: IMPLEMENTATION\n\n## Set up the project structure\nSet up the project structure according to the language-specific guide (package or module structure, dependencies, configuration files).\n\n## Core infrastructure\nBuild shared building blocks: an API client with authentication, error handling, response formatting (JSON or markdown) and pagination support.\n\n## Implement the tools\nFor every tool:\n- Input schema with Zod (TypeScript) or Pydantic (Python), with constraints, clear descriptions and examples.\n- Output schema where possible, for structured data.\n- A concise function description with parameters and return type.\n- Asynchronous processing for I/O operations, clean error handling with concrete hints, pagination where applicable.\n- Annotations: readOnlyHint, destructiveHint, idempotentHint, openWorldHint.\n\n# PHASE 3: REVIEW AND TEST\nCheck the code for duplication, consistent error handling, complete typing and clear tool descriptions.\n\nTypeScript: verify the build with npm run build, test with the MCP Inspector (npx @modelcontextprotocol/inspector).\nPython: check syntax with python -m py_compile, also test with the MCP Inspector.\n\n# PHASE 4: CREATE EVALUATIONS\nCreate ten evaluation questions to check whether a language model can use the server productively.\n\nApproach: review the tools, explore the available data with read-only operations, formulate ten complex, realistic questions, solve each question yourself and verify the answer.\n\nEvery 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.\n\nFormat as an XML file:\n```xml\n