| name | mcp-server-builder |
| model | sonnet |
| description | Scaffolds production-ready MCP servers from OpenAPI specs with schema validation, named tool definitions, and versioning strategy. Use when: 'build MCP server from API', 'create tool server from OpenAPI', 'expose REST API to LLM agent', 'scaffold MCP from spec', 'convert API contract to tools'. |
| category | skill-forge |
| triggers | ["build MCP server from API","create tool server from OpenAPI","expose REST API to LLM agent","scaffold MCP from spec","convert API contract to tools"] |
| tier | 1 |
| agents | ["primary"] |
| tool_dependencies | ["file_system"] |
| inputs | [{"name":"openapi_spec","type":"string","description":"Path or URL to the OpenAPI spec (JSON or YAML) to convert into MCP tool definitions","required":true},{"name":"server_name","type":"string","description":"Canonical name for the MCP server (used in tool manifests and package naming)","required":true},{"name":"language","type":"string","description":"Implementation language — \"python\" or \"typescript\"","required":false}] |
| outputs | [{"name":"mcp_scaffold","type":"ref","format":"directory","description":"MCP server scaffold with tool manifest (JSON), starter server code (Python or TypeScript), and validation report"}] |
MCP Server Builder
Scaffolds production-ready MCP servers from OpenAPI specs. Treats the API contract as the source of truth and generates tool manifests + starter code with quality gates before publication.
Description
Converts OpenAPI paths/operations into named MCP tool definitions, generates server scaffolds in Python or TypeScript, enforces naming and description quality, validates manifests against common production failures, and applies a versioning strategy for safe evolution. Distinct from mcp-cloudflare-builder (Cloudflare-specific deployment) and mcp-builder (general MCP concepts) — this skill is spec-driven and language-agnostic.
When to Use
- Exposing an internal or external REST API to LLM agents via MCP
- Replacing brittle browser automation with typed, validated tools
- Sharing one MCP server across multiple teams or assistants
- Bootstrapping from an existing OpenAPI spec rather than hand-writing tool definitions
- Running quality checks before publishing MCP tools to a registry
Workflow
Step 1: Parse the OpenAPI Spec
Read the spec and extract:
- Paths and HTTP methods
operationId (use as canonical tool name when available)- Request parameters and body schemas
- Response schemas
- Authentication requirements
Step 2: Generate Tool Manifest
For each operation, create an MCP tool definition:
{
"name": "get_user",
"description": "Retrieve a user by ID. Returns full profile including email and role.",
"inputSchema": {
"type": "object",
"properties": {
"user_id": { "type"
