REST wrapper or agent-designed MCP server: why wrappers fail

The fastest way to ship an MCP server is to generate one tool per API endpoint. Your API has sixty endpoints, your server has sixty tools, done in a day.

It is also the most reliable way to produce a server nobody keeps installed.

Why it fails

A REST API and an MCP server do not have the same user.

An API serves a developer. They read the documentation, they understand the data model, they chain three calls in the right order because they designed the journey in advance. Fine granularity is a feature: it gives them control.

An MCP server serves a model. It chooses at call time, from names and descriptions, in a context shared with other servers. Fine granularity becomes a cost: every extra tool is one more chance to get it wrong.

Four symptoms give a wrapper away:

Tools that mean nothing on their own. patch_resource_v2 makes sense in a doc, not in a list of choices.

Unstated required sequences. You have to call A then B, and nothing tells the model, which calls B directly and fails.

Responses designed to be parsed. Two hundred fields of JSON where the agent uses one. It burns context and buries the signal.

No risk distinction. Reading and deleting look alike, so nothing triggers a confirmation.

What an agent-designed server does

It starts from intents, not resources. You list what users want to achieve, in their words, and build tools from that list. Often ten intents cover 90% of usage of a sixty-endpoint API.

It absorbs the sequences. If publishing means validating, generating and activating, the tool is called publish and does all three. The agent does not need to know your plumbing.

It returns what feeds the next decision. A short, readable response with the handle needed to continue. Not your full object.

It declares its risk. Read-only or destructive, annotated, so the client can require confirmation.

It fails instructively. An error message that says what is missing lets the model correct itself. That is the difference between a tool that works half the time and a tool that works.

The legitimate objection

"If I do not expose everything, my advanced users will be stuck."

True, and it is handled differently: one or two well-bounded generic tools cover the long tail, while ten intent tools cover the day-to-day. You are not sacrificing coverage, you are ranking it.

What does not work is putting all sixty at the same level and hoping the model sorts it out.

The three-step method

1. List twenty real requests, phrased by users, in their vocabulary
2. Group them into intents. You typically land on eight to fifteen groups
3. One tool per intent, with the sequences absorbed and the variation carried by parameters

Only then do you look at your API to work out the implementation. In that order. The reverse produces a wrapper.

The test that settles it

Connect your server alongside two others, take your twenty requests, and count how often the right tool is picked first try.

A wrapper sits around 60 to 70%. An agent-designed server clears 90%. That gap is the whole difference between a product people uninstall and one they keep.

FAQ

Should I throw away the existing wrapper?

Rarely. You keep the implementation and redo the surface: grouping, naming, descriptions, annotations, responses. That is a few weeks, not a rewrite.

How do I justify this internally?

With the measured selection rate. It is a number, it compares before and after, and it speaks to engineering leadership.

What if my API is the product?

Then you have two products with two different users. That is more work, but it is the actual situation.

Redo the surface rather than the server

The €950 audit measures your current server's selection rate and quotes the tool surface rework. A full build runs €4,500 to €7,500 depending on scope.

Interested? Talk about my MCP server →

Related reading

• How many MCP tools before the agent loses the thread
• Writing MCP tool descriptions the model actually understands
• What an MCP server costs in 2026