Developer pack
Claude Skill
MCP Server Builder
Builds a Model Context Protocol server exposing your tool/API/database as a resource AI agents can use.
What it does
Takes a service or data source (internal API, database, file system, third-party tool) and produces an MCP server that exposes it cleanly for Claude, Codex, Cursor, and other MCP-aware agents. Handles auth, rate limiting, tool descriptions that agents actually use correctly.
When to use
- ✓You have an internal tool/API/database you want AI agents to use safely
- ✓Your team uses multiple AI agents and wants one consistent tool interface across them
- ✓You're exposing data to AI agents and need scoped, auditable access (not "give the agent your DB password")
When not to use
- ✗You only need one agent to use one tool once — direct function calling is simpler
- ✗You don't have a service to expose yet — build the underlying tool first
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/mcp-server-builder.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: mcp-server-builder
description: Use when building a Model Context Protocol (MCP) server. Triggers on "MCP server", "expose to AI agents", "tool for Claude", or wrapping an API for agent use.
---
# MCP Server Builder
MCP is becoming the de facto protocol for letting AI agents discover and use tools. Done well, you get one tool definition that works across Claude, Codex, Cursor, Gemini CLI, and the rest. Done badly, you get an exposure surface that leaks data or that no agent uses correctly.
## Required inputs
1. **What you're exposing** — internal API, database, file system, third-party tool, etc.
2. **Read vs. write scope** — what agents can do, what they explicitly cannot
3. **Auth model** — how does the agent prove it's allowed
4. **Audience** — your own team only, or external developers / customers
## Output
### Tool definitions
For each tool the server exposes:
- **Name** (concise, descriptive, follows convention)
- **Description** — what it does AND when an agent should choose it over alternatives. Agents pick tools by description; vague descriptions → wrong choices.
- **Input schema** — strict, with examples for edge cases
- **Output schema** — what the agent will get back, including error shapes
- **Idempotency** — can this be called twice safely? Document it.
### Auth + scoping
- Per-agent credentials, not shared
- Scope each token to the minimum tools and data needed
- Audit log every call (agent ID, tool, args, timestamp, result)
- Rate limit per agent + per tool
### Error handling
Errors agents should retry: 5xx, transient timeouts. Errors they should NOT retry: 4xx, validation failures. Make this distinction explicit in error responses — agents read this.
### What NOT to expose
- Tools that take destructive action without a confirmation pattern
- Tools that return unbounded data (let the agent paginate)
- Tools whose output is itself untrusted (don't return user-controlled data as tool output without explicit framing)
## Testing
- Test with the actual agents you target (Claude, Cursor, etc.) — descriptions that work on one don't always work on others
- Test the error paths — agents handle them poorly if responses are weird
- Test under load — agents make MANY calls
## Anti-patterns
- Tool descriptions written for humans, not agents (no "user-facing" copy)
- Exposing one giant tool with 12 optional parameters (split into focused tools)
- Returning HTML or formatted text when JSON would be parseable
Example prompts
Once installed, try these prompts in Claude:
- Build an MCP server exposing our internal customer database (read-only). Agents should be able to look up by email, fetch order history, see support tickets. No write access.
- I have a Linear API integration. Wrap it as an MCP server so Claude Code can pull issue context when working on a branch.