Don't wrap REST APIs into MCP servers tool-for-endpoint
logiQode argues that naively mapping REST API endpoints one-to-one into MCP tools produces slow, error-prone agents, and that tools should instead be designed around agent intents, not API surface.
Score breakdown
Design your MCP tools around what an agent needs to accomplish in one step — not what your REST API exposes — to reduce latency, token spend, and model reasoning errors in production.
- 01Mapping one MCP tool per REST endpoint forces models to chain multiple tool calls, increasing latency and token cost.
- 02Anthropic's guidance explicitly recommends grouping MCP tools around agent intent, not API endpoints.
- 03A single `triage_request` tool can fan out multiple HTTP calls internally using `Promise.all`, hiding round-trips from the model.
logiQode's post on Dev.to challenges the widespread practice of building MCP servers as thin HTTP client wrappers over existing REST APIs. The article illustrates the problem with a customer support platform example: a naive implementation creates separate tools for `list_responses`, `get_response`, and `update_response`, mirroring the REST endpoints directly. This forces the model to chain three or four tool calls to accomplish what a single well-designed tool could do in one, multiplying latency, token cost, and the risk of misinterpreting intermediate results. Citing Anthropic's own guidance, the post argues the right question is not "what does the API expose?" but "what does the agent need to accomplish?"
The example `triage_request` tool fans out two HTTP calls internally using `Promise.all`, assembles a clean summary object, and returns a single structured response.
The recommended alternative is to design tools around intents — triage a request, draft a reply, escalate, close — where each tool represents a single cognitive unit. The example `triage_request` tool fans out two HTTP calls internally using `Promise.all`, assembles a clean summary object, and returns a single structured response. The model sees one tool call and one answer; the parallelized HTTP work is an invisible implementation detail handled with proper error boundaries in one place.
The post also frames parameter descriptions as prompt engineering rather than documentation. A parameter typed as `z.string()` with no description forces the model to guess from context; a description like `"Unique identifier of the support response. Format: resp_XXXXXXXX"` is self-documenting at exactly the moment it matters — inside the model's prompt. The article further warns against returning raw `JSON.stringify(res.data)` to the model, comparing it to handing a junior analyst a raw database dump: it wastes context window on fields the model will never use and couples MCP behavior to the API's internal schema.
Key facts
- 01Mapping one MCP tool per REST endpoint forces models to chain multiple tool calls, increasing latency and token cost.
- 02Anthropic's guidance explicitly recommends grouping MCP tools around agent intent, not API endpoints.
- 03A single `triage_request` tool can fan out multiple HTTP calls internally using `Promise.all`, hiding round-trips from the model.
- 04Parameter descriptions in MCP schemas function as prompt engineering — vague descriptions cause models to hallucinate parameter values.
- 05Returning raw `JSON.stringify(res.data)` wastes context window and couples MCP behavior to the API's internal schema.