Mcp server builder
Skill yeaight7/agent-powerups/plugins/mcp-development/skills/mcp-server-builder
Design high-quality MCP servers around workflows, narrow schemas, context-aware outputs, and actionable errors. Use when building or reviewing MCP tools for real agent tasks.From its SKILL.md
npx -y skills add yeaight7/agent-powerups --skill mcp-server-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.5 KB, 731 tokens by cl100k_base, as published. Nobody here has run it
MCP Server Builder
Use this skill when designing or implementing an MCP server.
When to Use
- Building a new MCP server from scratch.
- Refactoring a weak or over-thin MCP tool surface.
- Reviewing whether a server exposes the right workflows.
- Designing evaluation cases for MCP usability.
Core Principles
- Build workflow tools, not thin endpoint wrappers — one tool should complete a meaningful agent task, not expose a single API method.
- Keep input schemas narrow and typed — reject unknown fields; use enums over free strings where possible.
- Return high-signal, size-bounded outputs — default to concise; add
detailorverboseflags when larger payloads are occasionally useful. - Make error messages corrective — tell the agent what to do next, not just what went wrong.
- Prefer human-meaningful identifiers over opaque IDs when both are available.
- Design evaluation cases before declaring the server "done".
Workflow
1. Map the workflow
- Identify the real tasks an agent must complete, not the underlying API surface.
- Merge low-level steps into meaningful operations (e.g., one
create_and_publishtool instead of separatecreate,validate,publish).
2. Design the tool surface
tool name: stable, verb-noun, describes the workflow step
input schema: typed, narrow, required fields only + optional detail flags
output shape: consistent structure across all tools in the server
failure modes: named error codes + correction hint
3. Design for context limits
- Default response fits in ~500 tokens for list operations, ~1500 for detail operations.
- Add
limit,page, orsummaryparameters for large result sets. - Truncate deterministically (e.g., top N by recency) — never truncate randomly.
4. Design corrective errors
Bad error: "Error: 404 Not Found"
Good error: "Resource 'project-123' not found. Use list_projects to see available project IDs."
Every error should tell the agent its next valid action.
5. Implement shared infrastructure first
- Auth handling and token refresh.
- Retry logic with exponential backoff and rate-limit awareness.
- Pagination helpers.
- Output formatting helpers (consistent truncation, redaction of secrets).
6. Evaluate before shipping
- Write representative task scenarios (not unit tests for individual tools).
- Check whether an agent can complete the full workflow using only the exposed tools.
- Redesign weak tools before adding more tools — more tools is not always better.
Server Readiness Checklist
- Every tool completes a meaningful workflow step.
- All inputs are typed and schema-validated.
- Output size is bounded by default.
- All error messages include a correction hint.
- Auth and retry are handled in shared infrastructure.
- At least one end-to-end task scenario has been tested.
- No secrets appear in tool outputs or error messages.
Local References
reference/mcp_best_practices.mdreference/python_mcp_server.mdreference/node_mcp_server.mdreference/evaluation.md
Use the Python and Node references only for the stack you are actually shipping.
Bundled Scripts
scripts/evaluation.py— evaluation scaffoldingscripts/connections.py— connection-oriented examples
Use them as optional helpers, not mandatory runtime requirements.
What ships with it: 8 files
120.2 KB alongside SKILL.md, 2 of them executable
reference/
- evaluation.md21.1 KB
- mcp_best_practices.md27.7 KB
- node_mcp_server.md26.1 KB
- python_mcp_server.md25.6 KB
scripts/
- connections.pyruns4.8 KB
- evaluation.pyruns13.7 KB
- example_evaluation.xml1.2 KB
- requirements.txt37 B
Gives 0 of the 12 instructions most mcp tooling skills give in 731 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
- Keep input schemas narrow and strictly typed
- Return high-signal and size-bounded outputs
- Use human-meaningful identifiers over opaque IDs
- Design evaluation cases before declaring completion
- Merge low-level steps into meaningful operations
- Implement shared infrastructure for auth and retries
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.