---
name: mcp-builder
description: ALWAYS use this when the user wants to build, extend, debug, or wire up an MCP server, tool connector, tool schema, or agent-facing external capability.
MCP Builder
Selective Reading Rule
Start with:
references/usage-routing.md
references/quality-checklist.md
Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.
Purpose
Create MCP servers that are easy for agents to discover, understand, and use effectively in real tasks.
Selective Reading Rule
Start with:
references/senior-master-standard.md
references/server-design-checklist.md
references/eval-planning.md
Then load the legacy reference/ docs that match the implementation language or evaluation task.
Recommended Process
- Research the target API or service.
- Review the MCP specification and framework guidance.
- Plan tool coverage and resource design.
- Implement the server with clear schemas and actionable errors.
- Test the server and build evaluations.
Design Principles
- Prefer clear, action-oriented tool names.
- Balance broad API coverage with useful workflow tools.
- Keep tools focused on one job each.
- Return predictable structured data when possible.
- Add pagination and filtering so agents can manage context efficiently.
- Write errors that help the agent recover with a concrete next step.
Core Areas
Tools
- Validate inputs with strong schemas.
- Describe parameters clearly.
- Mark annotations such as read-only, destructive, idempotent, and open-world behavior when supported.
Resources
- Use static resources for fixed docs or config.
- Use dynamic resources for generated views.
- Use templates when URI parameters help agents target the right data.
Transport
- Prefer
stdio for local servers.
- Prefer stateless HTTP for remote servers unless a stateful transport is clearly needed.
Security
- Validate all external input.
- Limit resource scope.
- Keep secrets in environment variables.
- Avoid exposing internal implementation details in user-facing errors.
Testing
- Run build or syntax verification before finishing.
- Test with MCP Inspector when possible.
- Cover unit logic, integration behavior, and schema contracts.
Evaluations
After implementation, create read-only evaluations that require realistic multi-step reasoning and have stable answers.
References
Load these as needed:
references/server-design-checklist.md
references/eval-planning.md
reference/mcp_best_practices.md
reference/node_mcp_server.md
reference/python_mcp_server.md
reference/evaluation.md
Runtime Assets
Use bundled files in scripts/ for evaluation support and related utilities when they fit the task.
1---2name: mcp-builder3description: ---4---5---6name: mcp-builder7description: ALWAYS use this when the user wants to build, extend, debug, or wire up an MCP server, tool connector, tool schema, or agent-facing external capability.8---910# MCP Builder1112## Selective Reading Rule1314Start with:1516- `references/usage-routing.md`17- `references/quality-checklist.md`1819Then load only the inherited docs, scripts, assets, or examples that match the user's actual task.2021## Purpose2223Create MCP servers that are easy for agents to discover, understand, and use effectively in real tasks.2425## Selective Reading Rule2627Start with:2829- `references/senior-master-standard.md`30- `references/server-design-checklist.md`31- `references/eval-planning.md`3233Then load the legacy `reference/` docs that match the implementation language or evaluation task.3435## Recommended Process36371. Research the target API or service.382. Review the MCP specification and framework guidance.393. Plan tool coverage and resource design.404. Implement the server with clear schemas and actionable errors.415. Test the server and build evaluations.4243## Design Principles4445- Prefer clear, action-oriented tool names.46- Balance broad API coverage with useful workflow tools.47- Keep tools focused on one job each.48- Return predictable structured data when possible.49- Add pagination and filtering so agents can manage context efficiently.50- Write errors that help the agent recover with a concrete next step.5152## Core Areas5354### Tools5556- Validate inputs with strong schemas.57- Describe parameters clearly.58- Mark annotations such as read-only, destructive, idempotent, and open-world behavior when supported.5960### Resources6162- Use static resources for fixed docs or config.63- Use dynamic resources for generated views.64- Use templates when URI parameters help agents target the right data.6566### Transport6768- Prefer `stdio` for local servers.69- Prefer stateless HTTP for remote servers unless a stateful transport is clearly needed.7071### Security7273- Validate all external input.74- Limit resource scope.75- Keep secrets in environment variables.76- Avoid exposing internal implementation details in user-facing errors.7778## Testing7980- Run build or syntax verification before finishing.81- Test with MCP Inspector when possible.82- Cover unit logic, integration behavior, and schema contracts.8384## Evaluations8586After implementation, create read-only evaluations that require realistic multi-step reasoning and have stable answers.8788## References8990Load these as needed:9192- `references/server-design-checklist.md`93- `references/eval-planning.md`94- `reference/mcp_best_practices.md`95- `reference/node_mcp_server.md`96- `reference/python_mcp_server.md`97- `reference/evaluation.md`9899## Runtime Assets100101Use bundled files in `scripts/` for evaluation support and related utilities when they fit the task.