agentsclimarketplace
Sign in

Mcp server builder

Skill alirezarezvani/claude-skills/engineering/skills/mcp-server-builder

Design and ship production-ready MCP (Model Context Protocol) servers from OpenAPI contracts instead of hand-written tool wrappers. Python and TypeScript support, schema validation, safe evolution. Use when exposing an existing API as an MCP server, building tool integrations for Claude or Codex or Cursor, or scaffolding an MCP project from scratch.From its SKILL.md

Install
npx -y skills add alirezarezvani/claude-skills --skill mcp-server-builder

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

3.9 KB, 744 tokens by cl100k_base, as published. Nobody here has run it

MCP Server Builder

Tier: POWERFUL · Category: Engineering · Domain: AI / API Integration

Overview

Use this skill to design and ship production-ready MCP servers from API contracts instead of hand-written one-off tool wrappers. It focuses on fast scaffolding, schema quality, validation, and safe evolution.

The workflow supports both Python and TypeScript MCP implementations and treats OpenAPI as the source of truth.

Core Capabilities

  • Convert OpenAPI paths/operations into MCP tool definitions
  • Generate starter server scaffolds (Python or TypeScript)
  • Enforce naming, descriptions, and schema consistency
  • Validate MCP tool manifests for common production failures
  • Apply versioning and backward-compatibility checks
  • Separate transport/runtime decisions from tool contract design

When to Use

  • You need to expose an internal/external REST API to an LLM agent
  • You are replacing brittle browser automation with typed tools
  • You want one MCP server shared across teams and assistants
  • You need repeatable quality checks before publishing MCP tools
  • You want to bootstrap an MCP server from existing OpenAPI specs

Key Workflows

1. OpenAPI to MCP Scaffold

  1. Start from a valid OpenAPI spec.
  2. Generate tool manifest + starter server code.
  3. Review naming and auth strategy.
  4. Add endpoint-specific runtime logic.
python3 scripts/openapi_to_mcp.py \
  --input openapi.json \
  --server-name billing-mcp \
  --language python \
  --output-dir ./out \
  --format text

Supports stdin as well:

cat openapi.json | python3 scripts/openapi_to_mcp.py --server-name billing-mcp --language typescript

2. Validate MCP Tool Definitions

Run validator before integration tests:

python3 scripts/mcp_validator.py --input out/tool_manifest.json --strict --format text

Checks include duplicate names, invalid schema shape, missing descriptions, empty required fields, and naming hygiene.

3. Runtime Selection

  • Choose Python for fast iteration and data-heavy backends.
  • Choose TypeScript for unified JS stacks and tighter frontend/backend contract reuse.
  • Keep tool contracts stable even if transport/runtime changes.

4. Harden for Production

Key items before publishing:

  • Keep secrets in env vars, not tool schemas
  • Prefer outbound host allowlists over open proxies
  • Use additive-only changes; never rename tool names in-place

Full hardening guidance: references/production-hardening-guide.md.

Script Interfaces

  • python3 scripts/openapi_to_mcp.py --help
    • Reads OpenAPI from stdin or --input
    • Produces manifest + server scaffold
    • Emits JSON summary or text report
  • python3 scripts/mcp_validator.py --help
    • Validates manifests and optional runtime config
    • Returns non-zero exit in strict mode when errors exist

Reference Material

What ships with it: 8 files

22.0 KB alongside SKILL.md, 2 of them executable

references/

scripts/

Gives 0 of the 12 instructions most mcp tooling skills give in 744 tokens

Counted across 780 of the 1,136 authors here whose files we hold, read 2026-09-06

  • Use Zod for input validationin 34 of 780, across 21 files
  • Use stdio for local clientsin 27 of 780, across 10 files
  • Restart Claude Code after configurationin 26 of 780, across 23 files
  • Verify MCP server connection before using toolsin 23 of 780, across 17 files
  • Define input schemas for every toolin 20 of 780, across 11 files
  • Use Streamable HTTP for remote clientsin 18 of 780, across 8 files
  • Pin SDK version in package.jsonin 17 of 780, across 6 files
  • Keep server logic independent of transportin 16 of 780, across 6 files
  • Verify SDK methods against official documentationin 15 of 780, across 5 files
  • Format evaluation results as an XML filein 15 of 780, across 12 files
  • Test servers using the MCP Inspectorin 15 of 780, across 14 files
  • Create ten complex and independent evaluation questionsin 14 of 780, across 11 files

Said here and by no other author read

  • use OpenAPI specs as the source of truth
  • generate server scaffolds from OpenAPI contracts
  • validate tool manifests before integration tests
  • keep tool contracts stable across runtime changes
  • use outbound host allowlists
  • apply additive-only changes to tool definitions

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.