Every tool is shipping an MCP server now — when is writing one actually worth it?

Where it earns its keep, in my experience:

• Many clients, one service. Several assistants, several teams, people using different tools. The protocol means you describe your capability once.
• Capabilities that change. Runtime discovery means clients pick up new tools without redeploying anything.
• You are a product and your users have assistants. This is the case driving the wave you noticed. It is a distribution channel, and treating it as marketing rather than engineering is the correct read.

Where it does not:

• One caller you control. Call the API.
• High-volume or latency-sensitive paths. There is overhead, and the protocol is aimed at interactive use rather than at a hot loop.
• Anything where the hard part is authorisation. Wrapping an API does not answer who is allowed to do what, and that question gets harder, not easier, when an agent is the caller.

The honest answer is that it buys you distribution and description, not capability.

Your REST API can already be called by an agent. What it cannot do is show up in somebody's assistant without that person writing an integration. The protocol standardises three things:

• Discovery — a client asks what tools exist and gets back names, descriptions and argument schemas, at runtime.
• Invocation — one transport and one shape for calling them, so a client that speaks it can use any server without bespoke code.
• Context beyond tools — resources and prompts, which is the part people forget exists and the part that distinguishes it from "a list of functions".

So the value is that a user of any compatible assistant can point it at your server and immediately have your capabilities, with no work by you or them.

If your service is internal and used by one agent that you also wrote, that value is close to zero. You already control both ends; a wrapper adds a hop and a spec to maintain.

The under-discussed cost: tool descriptions are prompt, and prompt is a budget.

Every tool your server exposes puts its name, description and argument schema into the model's context on every turn. Twenty tools with generous descriptions is a meaningful slice of the window before the user has said anything, and it measurably degrades selection accuracy — models get worse at choosing when the menu is long.

So a server exposing forty operations because the REST API has forty endpoints is actively harmful. The good ones expose a small number of task-shaped tools, not a mechanical mirror of an API surface.

That is the design work, and it is the part that mechanical wrapper generators skip. If somebody proposes generating a server from your OpenAPI spec, that is the failure mode to argue against.

One practical note before you commit: check what your users' assistants actually support today, because the ecosystem is moving quickly and support for the less-used parts of the spec is uneven.

Tools are supported broadly. Resources, prompts and the more elaborate transports much less so. Building around a part of the protocol that most clients ignore is a real way to spend a week for nothing.

The cheap experiment: expose two tools, ship it, and see whether anybody connects to it before building the other eighteen.