agentsclimarketplace
Sign in

Mcp server scaffold

Skill jpantsjoha/ai-native-developer-experience/.agents/skills/mcp-server-scaffold

Scaffold and govern an MCP server as a bounded tool seam. Defines which tools the agent may call, enforces the principle that agents call tools and tools call infrastructure. Trigger when adding or reviewing an MCP server in an agent system.From its SKILL.md

Install
npx -y skills add jpantsjoha/ai-native-developer-experience --skill mcp-server-scaffold

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

  • 11 stars11 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.6 KB, 738 tokens by cl100k_base, as published. Nobody here has run it

MCP Server Scaffold

Agents call tools. Tools call infrastructure. This boundary is the governance seam. Do not collapse it.

An MCP server is a contract between an agent and the capabilities it is allowed to use. Its value is not in what it exposes — it is in what it deliberately withholds.

When to use

  • Adding a new MCP server to an agent system
  • Reviewing an existing MCP server for scope creep or security gaps
  • Deciding which capabilities to expose to an agent (and which to explicitly deny)
  • Governing an agent that has been given "too much access"

Procedure

  1. Define the tool seam — before writing any server code, list:

    • What capabilities does the agent legitimately need?
    • What capabilities does the underlying system have that the agent must NOT access?
    • What is the minimum viable tool surface?

  2. Author the tool manifest — for each tool:

    Tool: <name>
Description: <one sentence — what it does and when to call it>
Input schema: <typed fields with constraints>
Output schema: <typed fields>
Side effects: <what it changes in the world — none / read-only / write / external-call>
Auth required: <yes/no and mechanism>
Rate limit: <calls/minute or none>

  3. Enforce least-privilege at the server — the MCP server holds the credentials and enforces the scope. The agent receives only the tool interface. Key rules:

    • Read tools and write tools are separate, explicitly named operations.
    • No tool exposes raw SQL, raw shell execution, or raw filesystem access.
    • No tool accepts arbitrary code or query strings from the agent without validation.

  4. Add input validation at the boundary — every tool validates its inputs before executing. Reject malformed inputs with a structured error, not an exception trace.

  5. Log every tool invocation — at minimum: tool name, caller identity, input summary (no secrets), output summary, timestamp, and latency. These logs are your audit trail.

  6. Test the refusal surface — confirm that:

    • A call to a non-existent tool returns a clean error, not a server crash.
    • An out-of-scope request (e.g. an agent trying to read data it is not authorised for) is rejected with a clear error.
    • Invalid inputs are rejected before any side effect occurs.

  7. Document the scope boundary — in the MCP server's README or SKILL.md, explicitly state what the server does NOT expose and why. Scope boundaries that are not documented drift.

  8. Run the Adversarial Gate — common MCP failure modes: overly broad tool descriptions that invite misuse, missing input validation that allows prompt injection via tool arguments, write tools with no confirmation step, no rate limiting on expensive operations.

Outputs

  • Tool manifest (one entry per tool)
  • MCP server skeleton with input validation and structured error responses
  • Refusal surface test cases
  • Scope boundary documentation

Guardrails

  • No raw database access through an MCP tool. Tools call repositories or services; repositories call databases.
  • Tool descriptions are part of the attack surface. Vague descriptions invite misuse by the agent. Be precise.
  • No secrets in tool outputs. If a tool must return an identifier, return the identifier — not the credential.
  • Scope creep is the default failure mode. When in doubt, add a new tool rather than broadening an existing one.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most project setup skills give in 738 tokens

Counted across 1,553 of the 3,091 authors here whose files we hold, read 2026-09-06

  • Write the configuration filein 36 of 1553
  • Create the directory structurein 35 of 1553, across 33 files
  • Verify the setupin 31 of 1553, across 28 files
  • Run the setup scriptin 30 of 1553, across 29 files
  • Pre-determine the required sample sizein 29 of 1553, across 12 files
  • Check if the configuration already existsin 29 of 1553
  • Document every testin 26 of 1553, across 10 files
  • Start with a hypothesisin 26 of 1553, across 11 files
  • Ask one question at a timein 22 of 1553
  • Test a single variable per testin 21 of 1553, across 9 files
  • Read product marketing context before asking questionsin 19 of 1553, across 8 files
  • Do not peek and stop earlyin 18 of 1553, across 7 files

Said here and by no other author read

  • Define the tool seam before writing code
  • Author the tool manifest for each tool
  • Enforce least-privilege at the server
  • Add input validation at the boundary
  • Log every tool invocation
  • Test the refusal surface

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.

Keep looking

Skills are one crate of 325,949. 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.