Stop Generating MCP Servers from REST APIs!

This might be the most common MCP antipattern I see, and it's not helped by a bevy of startups and products offering to automate this process for you. Of course, it's tempting: APIs are APIs after all, right?

Wrong.

MCP is built on top of (JSON)-RPC, which is centered on actions, while REST is focused on resources and communicating them between the client and server. And while there are similarities, the differences really pop up when designing tools for agents with MCP.

One of the biggest issues is that well-designed REST APIs are granular, composable, and stateless. This poses a problem for MCP servers and for agent tool use in general: too many tools confuse the model and can drastically reduce tool-choice performance, even if they're well-segregated via names and descriptions.

Even more glaring is the cost associated with a single action taking many tool calls: every tool call has several costs associated with it: tool choice error, latency, and model invocation cost.

If you need to make 5 REST API calls to complete an action, and your own evaluations have found a tool choice error rate for any tool as 5%, rather than having a 95% chance of success for a single tool call, your probability of success drops to ~77% ($P_{TOTAL} = P_1 * ... * P_5 = 0.95^5 = 0.7738...$), leaving you a 23% error rate for this one action: almost 5 times the rate you'd get from calling a single tool that does the entire action.

Beyond accuracy, every necessary tool call costs a conversation turn - a prompt must be sent to the model and an answer retrieved from it, even for choosing a tool. This compounds your token cost and your latency cost. If your roundtrip latency is 0.1s, your latency per action becomes at least 0.5s (ignoring transient network effects), which can be a long time for your user to wait.

Your token cost will go up as well. Testing with a simple calculator server (which you'll be able to find in AI Agents with MCP) running against Claude Sonnet 4, the initial GetPromptRequest costs about 1400 input tokens ($X_{IN_0}$) and 110 output tokens ($X_{OUT_0}$). The input token count includes the system prompt, the user prompt, and the set of available tools and their descriptions. For each subsequent request, which is a CallToolRequest, the input token size is the sum of the previous turn's input and output tokens, plus around 27 additional tokens ($X_{IN_i} = X_{IN_{(n-1)}} + X_{OUT_{(n-1)}} + 27 = X_{IN_0}(i + 1) + X_{OUT}i! + 27i!$ where $i$ is the number of tool calls) and the output token size averaged around 100 tokens, leaving with a total of $100(i + 1)$ output tokens.

This is for a pretty simple server, but let's use this as a ballpark. A single action requiring 5 tool calls using these estimates would cost something like 23,640 input tokens (vs. 2,927 for a single tool call) and 600 output tokens (vs. 200 for a single tool call). Using current Claude Sonnet 4 pricing, this comes out to \$0.07 in input tokens per action (vs. ~\$0.00878) and \$0.009 in output tokens per action vs. \$0.003. In total each action with five simple tool calls costs \$0.08 versus ~\$0.012 per action, an almost 7x increase. These numbers seem small, but this is just one action per user. In real-world usage this just means model bill go brrrrrr.

Taken all together, you shouldn't want to do this!

If you take one thing away from this, it's this: organize your MCP tools around actions your agent will take, and hide any composability from the agent. This gives you the benefits of a composable system (reusability, testability, etc.).

S/o to Jeremiah Lowen from Prefect for organizing these issues on his blog here.