Mcp server builder
Skill andrey-learning-machines/swe-harness/plugins/swe-harness/skills/mcp-server-builder
Portable SWE harness plugin for Codex and Claude Code
npx -y skills add andrey-learning-machines/swe-harness --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
- 1 stars1 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.
What its author says it does
Copied from the file, not written here
Use when designing, implementing, deploying, or reviewing Model Context Protocol (MCP) servers, especially remote HTTP MCP servers, tool schemas, write-capable tools, connector metadata, authentication, authorization, prompt-injection defenses, audit logging, deployment smoke tests, or quality assurance for MCP integrations.
SKILL.md
3.8 KB, as published. Nobody here has run it
MCP Server Builder
Overview
Use this skill to build Model Context Protocol (MCP) servers that are predictable for language models, safe for users, and easy to test. Prefer small, purpose-built tools with strict schemas, explicit metadata, server-side authorization, and clear quality gates.
Workflow
-
Define the trust boundary.
- Identify the MCP client, MCP server, downstream systems, secrets, network path, and deployment environment.
- Choose the narrowest authority that can complete the user workflow.
- For data writes, route through the owning service or application programming interface (API) rather than bypassing service boundaries.
-
Design the tool surface.
- Use intent-based names like
ped.populate_table_from_spreadsheet. - Keep each tool focused on one job.
- Write descriptions that say when to use the tool, when not to use it, what it changes, and what each parameter means.
- Use strict JSON Schema: required fields, enums for allowed values, formats, limits, and
additionalProperties: false. - Return
structuredContentthat conforms tooutputSchema, plus a concise text summary for compatibility. - For write tools, set annotations honestly:
readOnlyHint: false,destructiveHintbased on overwrite behavior,openWorldHintbased on external publication, andidempotentHintwhen repeat calls are safe.
- Use intent-based names like
-
Make writes safe by construction.
- Prefer validate or dry-run flows before commit flows.
- Require idempotency keys for create/update operations.
- Allow create and update only through explicit allowlists of resources and fields.
- Do not expose delete, raw query, arbitrary table, arbitrary endpoint, shell, or pass-through tools unless the user explicitly asks and a security review approves it.
- Require human confirmation for irreversible operations and server-side checks even when the client also asks for confirmation.
-
Implement the protocol cleanly.
- Support
initialize,tools/list, andtools/callat minimum. - For hosted servers, prefer Streamable HTTP on a single endpoint such as
/mcp; Server-Sent Events (SSE) is acceptable when the client requires it. - Validate request shape, tool name, arguments, authentication, authorization, origin, and size before executing business logic.
- Use timeouts and bounded retries for downstream calls.
- Redact secrets and personally identifiable information from logs.
- Support
-
Verify before shipping.
- Unit-test tool handlers directly.
- Test JSON Schema rejection cases, not only happy paths.
- Run a local MCP client or inspector against
tools/listand representativetools/callrequests. - Run deployed smoke tests over HTTPS.
- Replay a golden prompt set: direct prompts, indirect prompts, and negative prompts where the tool should not be selected.
Read When Needed
references/tool-design.md: Use while drafting or reviewing tool names, descriptions, schemas, annotations, and outputs.references/qa-security.md: Use before enabling a write-capable MCP server, deploying externally, or connecting an agent to production-like data.
Done Criteria
An MCP server is ready only when the code, deployment, and seed/configuration agree on:
- exact tool names and endpoint URL
- authentication and authorization mechanism
- allowed resources and fields
- dry-run versus commit behavior
- audit logging and correlation identifiers
- automated tests and deployed smoke-test evidence
- rollback or disable path for the MCP server or connector