MCP server skills for AI agents

Ask an agent for a Model Context Protocol server and it will produce something that compiles, registers a tool, and looks entirely correct. The failures show up later and none of them are visible in the code: logs written to stdout that silently corrupt the protocol stream, a transport chosen from whatever the model absorbed months ago, tool descriptions nobody ever tested against an actual model. Handing the agent a skill is the obvious fix — except that the name you would reach for, mcp-builder, has been published under repository after repository over documents that share nothing but the name, and they disagree with each other on the parts that matter.

The useful discovery from reading them is that two sections tell you almost everything about a given document: its transport table and its testing section. The transport table dates it — some of these guides hand you Server-Sent Events as the remote option with no caveat, while others list SSE as legacy and say so in as many words. The testing section tells you what its author thinks "done" means: nothing at all, an Inspector window a human clicks through, or a check that a model can actually complete a task with the tools you built.

Top picks

The one that ends in an evaluation set, not a demo

waybarrios/opencode-power-pack/mcp-builder runs four phases — research, implementation, review, then evaluations — and the fourth is what separates it. It makes the agent write ten questions against the server it just built, each one required to be independent, read-only, complex, realistic, verifiable and stable, then emit them as XML qa_pair blocks; the stated purpose is that "Evaluations test whether LLMs can effectively use the MCP server to answer realistic, complex questions." Everything before that is disciplined too: outputSchema and structuredContent where the SDK supports them, the four tool annotations spelled out (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), and an instruction to fetch the protocol docs rather than recall them.

Two things to check before you vendor it. It says of itself, "This is a modified port of the upstream mcp-builder skill from anthropics/skills," and it is honest that the upstream's four bundled reference files are not included in the port — the remedy it offers is that "The reviewed upstream snapshot is pinned in UPSTREAMS.json," which tells you what it was ported from but does not give you the missing files. Its front matter also declares license: Apache-2.0 (modified; see UPSTREAMS.json) while the repository it ships in is catalogued under MIT, so resolve that before it lands in anything you distribute.

Both languages, end to end, plus where to look when it breaks

bobmatnyc/claude-mpm-skills/model-context is the long one, and the length is spent well: a full TypeScript walkthrough and a full Python walkthrough, resources and prompts in both, then transports, then debugging. The debugging section is the reason to keep it — it runs the Inspector and tells you it "Opens browser at http://localhost:6274", then sends you to the client's own logs with tail -f ~/Library/Logs/Claude/mcp*.log when the Inspector shows nothing. It also states the stdout rule plainly, that "STDOUT is for MCP protocol" and console.error is where your debug output belongs — break that rule and the server runs, answers nothing, and shows you nothing wrong in the code.

One caveat that matters in practice: its front matter sets user-invocable: false and disable-model-invocation: true, so it is not a skill your agent will reach for on its own — it is a reference you point at deliberately.

After the server runs: the hardening layer

yonatangross/orchestkit/mcp-patterns opens by telling you what it is not for, sending scaffolding work elsewhere and keeping "patterns, security, and advanced features" for itself. Its value is the set of traps that only show up once something is running: it warns that "The fastmcp fork and the mcp.server.fastmcp module are not the same package," lists description sanitisation and hash verification against rug-pulls among its security rules, and pairs the Inspector with the client's debug flag on the grounds that "Inspector gives you the client-side frame view, --mcp-debug gives you what Claude actually saw." It pins itself hard — front matter targets name @modelcontextprotocol/sdk at >=1.29.0 and mcp at >=1.27.0, and the metadata carries spec-version: "2025-11-25".

The pinning cuts both ways. A large share of the document is release-note detail for specific client builds, so if you are not on those versions those passages are noise, and the fourteen rules it indexes live in files it references rather than in the page itself — what you get inline is a decisions table, which is genuinely actionable but is not the rules. It also carries the same pair of front-matter flags as model-context — user-invocable: false and disable-model-invocation: true — so it will not fire on its own either; you point at it.

For .NET, take the .NET-only guide

managedcode/dotnet-skills/mcp is written for .NET and nothing else, and it behaves like a document with a specific reader in mind. It splits package selection three ways — ModelContextProtocol.Core for the smallest dependency set, ModelContextProtocol for most projects, ModelContextProtocol.AspNetCore for HTTP hosting — then covers attribute discovery via [McpServerToolType] and [McpServerTool], and its transport table marks HttpTransportMode.Sse "Legacy compatibility only; do not choose this for new servers." The instruction that earns it a place is about the client side: "Treat optional features as negotiated capabilities, not assumptions," with the concrete follow-through of checking ServerCapabilities before touching completions, subscriptions or logging.

Its anti-pattern table is short and every row is operational rather than stylistic — logging to stdout "Corrupts the protocol stream", returning huge payloads bloats context, filters are for cross-cutting policy and not business logic. It is pinned to v1.4.x SDK guidance and is worth nothing to you outside .NET, which is exactly the kind of thing the description should tell you and does.

Remote and deployed: the Workers path

null-shot/cloudflare-skills/building-mcp-server-on-cloudflare skips the protocol tutorial entirely and goes straight at deployment, which is why it stays short. It branches immediately on the decision that most changes the shape of the project — public or OAuth-protected — scaffolds each from its own template, gives you the wrangler.toml with the Durable Object binding and the migration entry, then tells you the server "runs at http://localhost:8788/mcp" so the Inspector has somewhere to point. Its troubleshooting list is the part written by someone who has hit these: verify the tool name matches exactly, "Ensure init() registers tools before connections", and "Check server logs: wrangler tail."

The rival on the same platform, secondsky/claude-skills/cloudflare-mcp-server, is built differently — it gives you a runnable quick start, a short concepts list and one example tool, then hands off to reference files of 704, 814, 326, 246 and 66 lines plus four templates, so the substance exists but past that opening you are installing an index and trusting the files behind it. Note also that its core-concepts line lists transports as "SSE, HTTP, WebSocket", which is not how several of the documents below describe the current set.

Telling two skills with the same name apart

Skill names are not namespaced, so a name is a topic, not an identity — the publisher and the body are the identity. A skill called mcp-builder can be a deprecation notice, a navigation index, a framework quickstart or a full four-phase methodology, and installing the wrong one costs you an afternoon. Three checks separate them fast.

Read the description before anything else, because some of them tell you outright. Shubhamsaboo/awesome-llm-apps/mcp-builder opens its description with "DEPRECATED: This skill has been replaced by mcp-app-builder." and gives you the install command for the replacement — a skill that fires its own retirement notice into the agent's context is doing you a favour, and the right response is to follow it.

Then check whether the page is the content or a map to it. mcp-use/mcp-use/mcp-builder states under its opening heading that "This file provides a NAVIGATION GUIDE ONLY." — though it is not empty, and its best passage is a terminal loop for verifying a tool or widget without the Inspector UI, aimed squarely at an agent iterating on its own server. Compare it with mcp-use/skills/mcp-builder from a second repository under the same account: same framework, entirely different document, self-contained, with the templates enumerated and an Inspector you "Access at http://localhost:3000/inspector to test tools, view resources, and try prompts." Same name, same account, and you cannot substitute one for the other.

Third, check the commands you are about to paste. shareAI-lab/learn-claude-code/mcp-builder is a clean, short Python-and-TypeScript starter, but its test step reads npx @anthropics/mcp-inspector python3 my_server.py, while the other guides that name the Inspector package spell it @modelcontextprotocol/inspector. Its next line saves it — piping a tools/list JSON-RPC frame straight into the server needs no package at all — but that is one command down, and an agent will run the first one.

What to read in the file before you install it

Open the transport table first. vudovn/ag-kit/mcp-builder lists two transports and says Streamable HTTP "replaced the deprecated HTTP+SSE transport", adding that WebSocket is not a standard transport and naming the spec release it is written against; affaan-m/ECC/mcp-server-patterns puts it as "Streamable HTTP is preferred for remote (Cursor, cloud). Legacy HTTP/SSE is for backward compatibility." Pixel-Process-UG/superkit-agents/mcp-builder says instead "Choose transport layer (stdio for CLI, SSE for web)", carries a full SSEServerTransport implementation with Express, and offers WebSocket for high-throughput cases. That is a live disagreement between documents, not a subtlety, and whichever side you land on you should land on it deliberately rather than by whichever skill your agent loaded first.

Then read the testing section, and treat "no testing section" as the answer it is. Then ask whether the document is willing to say it might be wrong: mcp-server-patterns names registerTool(), tool(), registerResource() and resource() but refuses to say which pair your SDK version exposes, telling you "The SDK API evolves; check Context7 (query-docs for \"MCP\") or the official MCP documentation for current method names and signatures" — it still hands you an install line and a server constructor you can paste, and stops one step short of the registration call, which costs you a lookup and buys a document that is much harder to render obsolete. Last, before any of this, check whether you need a server: curiositech/some_claude_skills/mcp-creator has a "Do NOT use MCP for:" list that sends pure domain expertise to a skill and "Local stateless operations (use Script)", and vasilyu1983/AI-Agents-public/agents-mcp reaches the same verdict from the other end with a build-vs-use table whose entry for a one-time data fetch reads "Don't use MCP; use WebFetch".

What this leaves you with

The stdout corruption, the transport you did not choose and the untested tool descriptions are all avoidable, and none of them are avoided by a skill named after the thing you are building. Take the four-phase mcp-builder published under waybarrios for the method, because a server that ends in ten verifiable evaluation questions has been checked against a model rather than against a human clicking through a debugger. Take model-context when you want both languages walked through and a debugging path that goes past the Inspector into the client's own logs, and mcp-patterns once the thing runs and the failures turn into fork confusion and injection through tool descriptions. If the target is .NET, the .NET-only guide negotiates capabilities instead of assuming them; if the target is a public URL, the Workers guide gets you deployed and tells you to check wrangler tail when the tools do not appear.

What you have avoided is the version trap. The transport table dates a document and the testing section grades the bar its author set, and both are a short read before you install anything. Telling two documents that share a name apart is a different job with its own three checks: read the description, which sometimes announces a deprecation outright; work out whether the page is the content or a map to it; and read the commands before you paste them. A skill called mcp-builder is a topic rather than a document, and only the file will tell you which one you are holding.