mcp-serverlisted

# MCP Server ## Purpose Build an MCP server that a model can use correctly. The protocol is straightforward; the difficulty is designing a tool surface that a language model uses well, which is a different problem from designing an API for a programmer. ## When to Use - Exposing a system's capabilities to an LLM client. - Wrapping an internal API for agent use. - Improving an MCP server whose tools the model uses incorrectly. ## Capabilities - Tool design: granularity, naming, schema, and descriptions. - Resources for read-only context. - Prompts as reusable, parameterized templates. - Transports: stdio for local, HTTP/SSE for remote. - Authentication and authorization. - Error returns that let a model recover. ## Inputs - The underlying system and its API. - The tasks a model should be able to accomplish. - The security boundary: what the model may do, and on whose behalf. ## Outputs - A server whose tool descriptions unambiguously state when each tool applies. - Errors that are instructive rather than merely accurate. - A test suite exercising the tools as a model would call them. ## Workflow 1. **Design around tasks, not endpoints** — Do not mirror your REST API one-to-one. A model needs `find_order_by_customer`, not `GET /orders` with fourteen optional query parameters. 2. **Write the description as if it were the prompt** — Because it is. State what the tool does, when to use it, when *not* to use it, and what it returns. This text determines whether the mode