There is a one-line function in FastMCP — FastMCP.from_openapi() — that takes any REST API with an OpenAPI spec and hands you back a working MCP server. No hand-written tool definitions, no glue code. Speakeasy, Stainless, and Azure API Management all ship the same button now. Point it at your spec, get an agent-ready server, ship before lunch.
It works. That is the whole problem.
The feature that its own author begged people to stop using#
The most telling document in this corner of the ecosystem is a blog post by Jeremiah Lowin, who wrote FastMCP — the library that made OpenAPI-to-MCP conversion trivial in the first place. The post is titled Stop Converting Your REST APIs to MCP. His framing is blunt: the conversion feature "became so popular that people stopped designing servers and started regurgitating REST APIs," and he felt compelled to ask them to stop.
His thesis fits in one sentence: an API built for a human developer will poison your AI agent.
The reasoning is worth sitting with, because it inverts what makes a REST API good. A well-designed REST API is generous. It offers hundreds of small, atomic, single-purpose endpoints, each with flexible parameters, because programmatic iteration is cheap — a human developer composes them in code and pays nothing for the abundance. Discoverability and granularity are virtues.
Feed that same abundance to a language model and every virtue flips. The model does not compose endpoints in a for-loop; it reads all of them into its context window and then reasons, in natural language, about which one to call. Lowin's image is exact: your agent "stops being a helpful assistant and becomes an obsessive API librarian, endlessly debating the nuances of your endpoints instead of achieving its actual behavioral goal."
The failure is measurable, and it has a shape#
This isn't taste. The degradation is quantified across the tool-use literature, and it moves in one direction: as the number of available tools grows, tool-selection accuracy falls. Studies surveying the space report accuracy losses ranging from single digits to catastrophic — 7% at the mild end, up to 85% for large catalogs — purely as a function of how many tools are on the table. TaskBench shows the same curve inside a single task: graph accuracy above 96% when one tool is involved, collapsing toward 25–40% once six to eight tools have to be coordinated.
There's also a hard wall, not just a slope. OpenAI's API caps a single request at 128 tools. A mid-sized REST API — think a CRM, a payments provider, a ticketing system — routinely exposes more endpoints than that. Convert it 1:1 and you don't get a slow agent; past the limit you get a request that won't even validate. An empirical 2026 study, From REST to MCP, set out to measure automated wrapping specifically and found what the practitioners already knew: naive, endpoint-for-endpoint generation produces servers that are technically correct and behaviorally poor.
The context an auto-generated MCP server spends before the agent does anything useful is not overhead. It is the thing that makes the agent worse.
Context pollution is the mechanism. A large auto-wrapped toolset can inject thousands of tokens of schema — parameter descriptions, enums, nested request bodies — into the model's working memory before it reads a single word of your actual instructions. Those tokens don't just cost money. They crowd out the reasoning space the model needs to pick correctly, which is why adding a plausible-but-irrelevant tool measurably lowers the odds it chooses the right one.
The deliverable was never the conversion#
Here is the part the one-click framing hides. Every serious OpenAPI-to-MCP tool ships the conversion and the machinery to undo most of it — because the second thing is the actual work.
FastMCP's converter is built on an ordered list of RouteMap objects. Each rule matches routes by method, path pattern, or tag and decides what they become; a special EXCLUDE type drops routes from the server entirely. There's a mcp_component_fn hook to rewrite each generated tool in place — rename it, rewrite its description in language a model understands, collapse its parameters. None of that exists to make conversion easier. It exists because the raw conversion is a starting point you are expected to carve down.
The discipline that replaces "wrap everything" is capability design. Lowin's recommended unit isn't the endpoint; it's the agent story: as an agent, given this context, I use these tools to achieve this outcome. You build only the tools that story needs. In practice that means fewer, fatter, task-shaped tools — one get_open_invoices that chains three REST calls behind the scenes, instead of exposing list_customers, list_invoices, and filter_by_status and praying the model orchestrates them. Krzysztof Sopyla's version of the same rule is the cleaner slogan: expose capabilities, not endpoints. Two to four good tools beat forty faithful ones.
What to actually do with the button#
Don't refuse the generator — it's the fastest way to a working scaffold, and for a small, coherent API (a dozen endpoints that already map to real user intentions) a near-1:1 conversion is fine. The failure mode is specific: it's the large, generous, human-facing API run through the converter untouched and shipped.
So treat from_openapi() as the first 10% of the job, not the last. Generate the server, then delete: EXCLUDE every read-your-own-writes and pagination-plumbing endpoint an agent will never call deliberately. Then consolidate: replace clusters of low-level tools with a handful named after outcomes, and rewrite each description for a reader who has never seen your API and never will. Measure the result the only way that matters — does the agent pick the right tool on the first try, with the smallest tool list that still covers the job.
The uncomfortable takeaway is that the difficulty of building a good MCP server has almost nothing to do with the protocol. MCP is easy. Deciding what not to expose is the whole discipline, and it's the one part no spec can auto-generate for you.
