What this prompt does
This prompt builds an MCP (Model Context Protocol) server that exposes [tool_count] tools for [domain], specifically [tools], implemented in [language] using [mcp_sdk]. It sets up the server with [transport_type] transport, defines each tool with JSON Schema parameters and examples, and adds resource definitions for [resources] with URI templates.
The structure works because an MCP server is consumed by an AI, and an AI needs precise, well-described contracts to use tools well. Strong input validation on every parameter, informative error messages instead of stack traces, and [auth_method] for sensitive operations make the server pleasant and safe for a model to call. Rate limiting, request tracing, integration tests simulating MCP client calls, and a README with claude_desktop_config.json setup round it into something you can publish and others can install.
The distinction between tools and resources is worth getting right. Tools are actions the model invokes with typed JSON Schema parameters, while resources expose read-only data like [resources] through URI templates the client can pull on demand. Keeping that boundary clean means the model knows when it is acting versus reading, and the request tracing and logging give you a clear record to debug exactly which call the AI made and why it succeeded or failed.
When to use it
- You want to expose your own tools or APIs in
[domain]to an AI through a standard protocol. - You need typed tool schemas with descriptions and examples so the model calls them correctly.
- You want to surface read-only data as MCP resources via
[resources]URI templates. - You need authentication on sensitive operations rather than wide-open tool access.
- You want integration tests that simulate real MCP client calls before you ship.
- You plan to distribute the server via npm or pip with proper publish configuration.
Example output
Expect a publishable MCP server in [language]: server setup with [transport_type] transport, [tool_count] tool definitions with JSON Schema and examples, resource definitions for [resources], input validation, error handling, [auth_method] integration, logging with request tracing, integration tests, and a README with the Claude Desktop config block. It usually includes npm or pip publish configuration.
Pro tips
- Write rich tool descriptions and examples; the model decides whether and how to call a tool largely from these, so vague descriptions cause misuse.
- Validate every parameter strictly. An MCP server that accepts bad input and fails deep inside is hard for the AI to recover from.
- Return informative errors, not stack traces — the model can often self-correct from a clear "missing field X" message.
- Use
stdiofor[transport_type]if you are targeting Claude Desktop locally; pick a network transport only when you need remote access. - Keep
[auth_method]out of the schema and in the environment, so credentials never leak into tool definitions. - Match
[tool_count]to a coherent[domain]; a focused server is easier for the model to reason about than a grab-bag of unrelated tools.
