agentsclimarketplace

Mcp builder

Skill byerlikaya/claude-starter-kit/plugin/skills/mcp-builder

Enterprise engineering workflow for Claude Code — not just prompts. AI agents that plan, build, audit, and ship with security gates, privacy checks, and approval-controlled commits. Safely adopt it into new or existing repositories.

Install
npx -y skills add byerlikaya/claude-starter-kit --skill mcp-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

  • 20 stars20 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

Build a Model Context Protocol (MCP) server so an AI client can call your tools/resources: design tool schemas, pick a transport, handle errors, and test it. For exposing an API, database, or service to Claude and other clients. Trigger phrases: "MCP server", "build an MCP", "model context protocol", "expose tools to Claude", "MCP tool"

SKILL.md

3.2 KB, 686 tokens by cl100k_base, as published. Nobody here has run it

MCP Builder

An MCP server exposes tools (actions the model can call), resources (data it can read), and prompts (reusable templates) to any MCP client over a standard protocol. The whole job is: design a small set of clear, well-described tools, validate their inputs, return useful errors, and prove it works with a real client. The protocol is easy; the design of the tools is what makes the server good or useless.

Kit adaptation (local, .claude/): Stack-agnostic — TypeScript (@modelcontextprotocol/sdk) or Python (mcp / FastMCP) are the maintained SDKs; match the project's language. §4 Prohibitions apply (no AI trace in generated code/strings). Secrets (API keys the server needs) go via env, never hardcoded — the kit's secret gates apply.

Design first (the tools ARE the product)

  • Few, purposeful tools — expose tasks, not a 1:1 mirror of every API endpoint. "create_invoice" beats "post_v2_billing_documents".
  • The description is the interface — the model routes on it. Say what it does, when to use it, and what it returns, in plain language. A vague description = an unused or misused tool.
  • Typed, validated inputs — a JSON-Schema for each tool; required vs optional explicit; enums over free strings where possible. Reject bad input with a clear message, don't guess.
  • Useful returns & errors — return structured, model-readable results; on failure return an actionable error ("no invoice with id X") not a stack trace. Never crash the server on bad input.
  • Least privilege — a tool does one scoped thing; destructive actions are explicit and, where possible, confirmable. Don't expose raw SQL / shell unless that is genuinely the product.

Checklist

  • Tools chosen by task, not by mirroring endpoints
  • Each tool has a clear description (what · when · returns) and a JSON-Schema input
  • Inputs validated; bad input → clear error, not a crash
  • Returns are structured and model-readable; errors are actionable
  • Transport chosen (stdio for local, HTTP/SSE for remote) — see references
  • Secrets via env; no hardcoded keys
  • Tested against a real client (Inspector + a live client)

Protocol, SDK skeletons, transport, and testing

Concrete server skeletons (TypeScript + Python), stdio vs. HTTP transport choice, resources/prompts (not just tools), and the test loop (MCP Inspector → real client): references/building.md.

Invariant rules

  1. Design the tools before writing them — task-shaped, few, clearly described.
  2. Validate every input — schema-checked; bad input returns an error, never crashes.
  3. Errors are for the model — actionable text it can recover from, not raw traces.
  4. Secrets via env only — never hardcode credentials the server needs.
  5. Prove it with a real client — a server that only "looks right" is untested.

Gives 1 of the 12 instructions most mcp tooling skills give in 686 tokens

Counted across 638 of the 750 authors here whose files we hold, read 2026-08-06

  • create ten complex read-only evaluation questionsin 71 of 638, across 17 files
  • test servers using MCP Inspectorin 60 of 638, across 18 files
  • provide actionable error messagesin 56 of 638, across 14 files
  • prioritize comprehensive API coverage over specific workflowsin 54 of 638, across 12 files
  • use TypeScript and Streamable HTTP for remote serversin 53 of 638, across 7 files
  • define structured output schemas where possiblein 51 of 638, across 9 files
  • use Zod or Pydantic for input schemasin 48 of 638, across 6 files
  • fetch MCP specification pages with markdown suffixin 46 of 638, across 4 files
  • load framework documentation using WebFetchin 45 of 638, across 3 files
  • verify each evaluation answer independentlyin 45 of 638, across 3 files
  • implement API client with authentication and paginationin 45 of 638, across 3 files
  • Define input schemas with validationhere, and in 28 of 638, across 10 files

Said here and by no other author read

  • expose tasks not mirrored endpoints
  • design tools before writing them
  • reject invalid input with a clear message
  • never crash the server on bad input
  • scope each tool to one action
  • test the server against a real client

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 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.