agentsclimarketplace

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

Install
npx -y skills add andrey-learning-machines/swe-harness --skill mcp-server-builder

Assembled 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

  1. 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.
  2. 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 structuredContent that conforms to outputSchema, plus a concise text summary for compatibility.
    • For write tools, set annotations honestly: readOnlyHint: false, destructiveHint based on overwrite behavior, openWorldHint based on external publication, and idempotentHint when repeat calls are safe.
  3. 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.
  4. Implement the protocol cleanly.

    • Support initialize, tools/list, and tools/call at 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.
  5. 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/list and representative tools/call requests.
    • 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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.