One server, many clients
We build an MCP server as a thin, well-typed boundary in front of an existing system — your CRM, your warehouse, your deployment pipeline. It advertises a small set of tools and resources, and any MCP-aware client can use them without knowing anything about the internals.
The payoff is leverage. The same server powers a customer-facing copilot, an internal ops assistant, and your IDE — and the day a better model ships, you point it at the same endpoint and move on.
What actually breaks
Tool descriptions are prompts. Vague schemas and fuzzy descriptions lead to the model calling the wrong tool with the wrong arguments, so we invest in precise types and examples the way we'd invest in an API contract.
The other failure mode is scope creep — exposing too much. We keep servers narrow, return only what's needed, and paginate aggressively so a single call can't drag a model's context window to its knees.
Security is not optional
Auth lives at the server, never in the prompt. Each tool checks permissions against the calling user, secrets stay server-side, and destructive operations are gated behind explicit confirmation. Every call is logged with arguments and result.
Treated as production infrastructure — versioned, monitored, rate-limited — an MCP server becomes a durable asset. Treated as a hackathon script, it becomes the most over-privileged process in your stack.