Every API team I talk to is getting the same request this year: "can our agents call this?" MCP is how agents call tools. You already have an OpenAPI spec. The distance between those two facts is smaller than it has ever been, so I spent a weekend running one spec through seven different approaches to find out exactly how small.
The test
I used one real OpenAPI 3.1 spec, different endpoints, a mix of API-key and OAuth2 auth, pagination, and a couple of file-upload endpoints. In other words, the stuff that breaks naive generators.
What I measured:
- Time to a working server. From spec to an agent successfully calling a tool.
- Tool quality. The names and descriptions the LLM actually sees. This matters more than anything else and almost nobody talks about it.
- Auth. What happens when the endpoint needs OAuth, not just a key in a header.
- Drift. What happens when the spec changes next Tuesday. A generated server is a snapshot.
- Day 2. Hosting, scopes, logs. Everything between "it runs on my laptop" and "I'd let a partner's agent call this."
The seven approaches
1. Hand-writing it with the official MCP SDK
The baseline. The TypeScript and Python SDKs are solid, and a hand-written server has the best tool descriptions of anything I tested, because a human wrote them for an LLM reader.
The cost is obvious: you write and maintain every tool. For a curated surface of five carefully designed tools, this is the right answer. For "expose our forty endpoints," it's a week of work that starts rotting the moment the API changes.
Best for: a small, deliberate tool surface where every description is crafted.
2. FastMCP
FastMCP can build a server directly from an OpenAPI spec (or straight from a FastAPI app), and the developer experience is genuinely delightful. Huge community and for Python teams it's the obvious default.
What it doesn't do: hosting, auth infrastructure, or regeneration. You own the deploy, and when the spec drifts, re-running the generation and redeploying is your job to wire up.
Best for: Python teams, internal tools, local stdio servers. If that's you, honestly, stop reading and use this.
3. openapi-mcp-generator (open-source CLI)
Spec in, server code out. Free, inspectable, and the output is yours to modify. This is the option open-source purists will (rightly) reach for.
The catch I hit: the generated tool descriptions are only as good as the descriptions in your spec. Mine were written for human API consumers years ago, so the generated tools were vague and the agent guessed badly. Garbage in, agent confusion out. That's not the generator's fault, but it's the reality of most specs in the wild.
Best for: teams that want code they own and are willing to improve their spec first.
4. Stainless
If you already use Stainless for SDK generation, MCP server output is essentially another target in the pipeline, and the quality inherits from everything their SDK tooling already knows about your API.
It's oriented around companies shipping official SDKs. For a side project it's overkill; for an API company it's a very clean story.
Best for: SDK-first companies that want docs, SDKs, and MCP from one pipeline.
5. Speakeasy
Similar lane to Stainless, with one side effect I appreciated: their spec linting pushes you to fix the description-quality problem from approach #3, which improves your generated tools whether or not you stay with them.
Best for: teams that want to invest in spec quality and generate multiple artifacts from it.
6. Postman's MCP generator
If your team lives in Postman, generating an MCP server from a collection is convenient and requires no new tools.
The structural issue: the collection is the input. Collections are maintained by hand, they describe what someone typed into a client, and they drift from the code the moment nobody updates them. Your MCP server inherits whatever drift the collection has. Hosting, per-tool scopes, and call logs are also on you.
Best for: Postman-native teams with well-maintained collections who want a quick start.
7. Elva https://getelva.ai/
Different starting point: instead of taking the spec as input, Elva reads the repo, generates the OpenAPI itself, and rescans on every commit, so the drift problem from approaches #2 through #6 doesn't exist because the spec is an output, not an artifact someone maintains. The MCP server is hosted, with OAuth2, per-tool scopes, field redaction, rate limits, and a log of which agent called which tool.
The pitch is the day-2 problem: not "generate a server" but "run one you'd let a partner's agent call and still trust it in three months."
Where it loses, so you don't have to guess: it's a hosted platform, not a library. If you want a local stdio server for a hobby project, FastMCP is better and you should use it. It's not open source. And the free tier covers one repo, so a personal multi-project setup won't be for free, but it is still cheap enough if you ask me.
Best for: production APIs with external consumers, partners, or agents, where governance and observability are requirements rather than nice-to-haves.
What actually separated them
Generation is the easy 20%. Every single tool above produced a server that technically worked. The differences that mattered were all downstream:
Tool descriptions are the whole game. The spec's descriptions become the agent's entire understanding of your API. Most specs were written for human developers who could read between the lines. Agents can't. The tools that either force you to fix descriptions (Speakeasy's linting) or generate and score them (Elva) produced noticeably better agent behavior than raw pass-through generation.
Auth is where half the field punts. API-key auth worked everywhere. OAuth2 separated the libraries (you build it) from the platforms (built in). If your API's interesting endpoints are behind OAuth, weight this criterion heavily.
Drift is the silent killer. A generated MCP server is a snapshot of the spec at generation time. Whatever mechanism regenerates and redeploys when the spec changes is your real architecture. For most of these tools, that mechanism is "you, remembering to."
Observability is how you sleep. When an agent starts calling a delete endpoint in a retry loop at 3am, "which agent, which key, which tool, how many times" is not a question you want to answer from gateway logs and vibes.
What I'd actually pick
Hobby project or internal Python tooling: FastMCP, no contest. Company already shipping SDKs: Stainless or Speakeasy, and your MCP story comes almost free. Team that lives in Postman with disciplined collection hygiene: the Postman generator is a fine start. Production API where partners' or customers' agents are the consumers and you need auth, scopes, and an audit trail: that's the gap I started Elva to fill, and approaches #1 through #6 are why I thought the gap was real.
Genuine question for the comments, because I don't think anyone has a great answer yet: when your spec changes, what regenerates and redeploys your MCP server? Cron job? CI step? A human? I'm collecting answers.
Top comments (0)