Everyone is shipping MCP servers right now. Almost nobody is shipping ones that survive contact with a real agent past week three.
I see it from the forward deployed seat every month. A team wraps their REST API one-to-one, exposes forty tools, and calls it an MCP integration. The demo lands. Then the agent starts stitching six primitive calls together to accomplish one task, the context window bloats, and retries quietly duplicate records. Nobody notices until someone checks the database on a Thursday.
Anthropic’s engineering team put the core failure mode in writing. Fewer, well-described tools consistently outperform exhaustive API mirrors. Don’t wrap your API into an MCP server one-to-one, group tools around intent, so the agent can accomplish a task in a couple of calls instead of stitching many primitives together. That is the whole game. And yet the default behavior of most teams, and most coding agents building these servers, is the exact opposite.
So here is the sequence I run. Three days. Not three weeks, not three sprints. If you cannot do it in three days, your scope is wrong.
Day one: outcomes, not endpoints
Do not open your API docs. Do not look at your schema. Sit down and write the three to five tasks an agent must be able to complete against your system. Full stop.
This is the step everyone skips, and it is the one that determines whether your server compounds or decays. Workato frames it as a completeness test: can 3-5 primary use cases be completed using only this server? The scope may be too narrow if most workflows require multiple servers. I would add the inverse: if it takes a paragraph to explain what your server is for, your scope is too wide.
The reason outcomes matter more than endpoints is that MCP servers are not built for you. Traditional APIs are built for human developers who read documentation, make deliberate choices, and write code to handle the response. MCP servers are built for LLMs that discover what your server can do from the descriptions you write, and act on these descriptions through inference rather than logic. You are writing for a reader who infers. Design accordingly.
The Cost of Doing Nothing shows up first here. Skip day one, and every downstream decision inherits ambiguity. You will pay for it in tool sprawl, in bloated context, and in an agent that cannot reliably pick the right call. That tax compounds silently for months.
Day two: the smallest surface that covers the work
Now, and only now, design tools. One per outcome where you can manage it.
Anthropic’s example is the whole lesson in one line. A single create_issue_from_thread tool beats get_thread + parse_messages + create_issue + link_attachment. Intent-level tools mean the agent does the work in two calls, not nine. Fewer calls means less context burned, fewer failure points, fewer chances for a retry to go sideways.
Keep the count honest. Workato’s rule of thumb: use tool count as a signal, use 5-8 tools per MCP server. If you are past that, you are probably back to wrapping endpoints.
There is one real exception, and it matters at enterprise scale. If your service requires hundreds of distinct operations, such as Cloudflare, AWS, or Kubernetes, an intent-grouped toolset likely won’t cover it. Instead, expose a thin tool surface that accepts code: the agent writes a short script, your server runs it in a sandbox against your API, and only the result returns. Do not reach for this pattern early. Reach for it when a curated toolset genuinely cannot cover the surface area.
While you are here, build for two readers at once. Structured, typed output for the model. Readable explanations for the human. And make your errors do work: keep error messages actionable by incorporating machine-readable codes along with brief explanations.
Idempotency is not optional. This is where the quiet database corruption comes from. Your server will be called by agents that may retry or parallelize the request. Make tool calls idempotent, accept client-generated request IDs, and return deterministic results for the same inputs.
Day three: evals and observability before you expose anything
The mistake that kills servers is shipping tools to a real agent before you can see what they do. Do not.
Wire observability first. Emit structured logs with correlation IDs, include tool name and invocation ID, record latency, success/failure, and token-cost hints if known. Then run your three to five day-one outcomes as evals against the real agent. If the agent picks the wrong tool, your descriptions are wrong. Fix the words, not the code.
The upfront cost is real and it is worth it. It requires a little bit more upfront investment. The return is that the integration is portable, and provides the semantics needed for a feature-rich agent integration.
Here is the punch. A decaying MCP server and a compounding one look identical in the demo. They diverge in production, and the divergence is a function of the three days you either spent or skipped. The Cost of Doing Nothing is not a line item you will see this quarter. It is the slow tax you pay every time an agent stitches nine calls to do the work of two.
Design for compounding. The teams who curate intent-level capabilities are going to eat the teams who exposed the most tools. Start Monday.