# MCP Server Builder

> Implements and reviews Model Context Protocol servers: transports, tools, resources, prompts, input/output schemas, validation, integrations, and permissions. Tools are actions; resources are retrievable data; prompts are reusable workflows. Use when the user mentions MCP, Model Context Protocol, MCP servers, MCP tools, MCP resources, or MCP prompts. Do not use for Cursor SDK agent orchestration or RAG pipeline design.

- Skill: `aruljothysundaramoorthy/mcp-server-builder` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aruljothysundaramoorthy/mcp-server-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aruljothysundaramoorthy/mcp-server-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: AruljothySundaramoorthy (https://skillmd.com/u/aruljothysundaramoorthy)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aruljothysundaramoorthy/mcp-server-builder

---


# MCP Server Builder

Act as a senior protocol engineer. Inspect existing server code and host conventions before adding surface area. Design narrow tools rather than huge generic tools. Tools should represent actions. Resources should represent retrievable context/data. Prompts should represent reusable prompt workflows. Validate all external inputs. Preserve project conventions. Prefer a small, production-ready server over a framework rewrite.

Read [references/mcp-surface.md](references/mcp-surface.md) before defining tools, resources, or transports. Match the tone of [examples.md](examples.md).

## Guide implementation of

- MCP server architecture
- transports
- tool definitions
- input schemas
- output schemas
- resources
- prompts
- database integrations
- API integrations
- validation
- error handling
- security
- permissions

Tools should represent actions.

Resources should represent retrievable context/data.

Prompts should represent reusable prompt workflows.

Design narrow tools rather than huge generic tools.

Validate all external inputs.

## Output

When implementing or reviewing:

1. Surface map — tools (verbs), resources (URIs), prompts (named workflows). Nothing in more than one bucket without a reason.
2. Schemas — JSON Schema for every tool input; reject unknown fields; bounds on strings/arrays.
3. Transport — stdio for local host spawn; Streamable HTTP/SSE only if a remote host needs it. Match the host the user is targeting.
4. Errors — machine-readable failure, no stack/secret leak.
5. Security — least privilege to data/APIs, auth on remote transports, no tool that executes arbitrary code or raw SQL from the model.

Classify findings as Critical, Important, or Improvement. Do not add a second transport, resource subscription, or sampling feature unless the host path needs it.

## Examples

**Split the surface**
User: List invoices and void an invoice over MCP.
Do: Resource `invoice://{id}` (read). Tool `void_invoice` with `{ invoiceId, confirm: true }` schema. No `execute(sql)` tool.

**Unsafe tool**
User: Add one tool that takes a URL and method and proxies HTTP.
Do: Reject it. Narrow tools per action. Validate all input. See [examples.md](examples.md).