By now the problem is clear: your API needs an agent-callable surface, and that surface is real infrastructure, not a weekend script. The good news is you have three legitimate ways to get there. The bad news is the vendors in each category describe the other two unfairly. So here's the comparison without the spin — including where our own approach fits, and where it doesn't.
Path 1 — Codegen: generate the server, then you operate it
Tools like Stainless and Speakeasy take your OpenAPI spec and generate high-quality client SDKs, and increasingly MCP servers, from it. Stainless was built by engineers who worked on OpenAI's SDKs and generates typed libraries "from your OpenAPI spec"; Speakeasy similarly generates SDKs and an MCP server from your API definition. [1] [2] If your spec is clean and current, this is a fast, high-quality way to get a server that mirrors your API.
The honest limit is in the word "mirrors." Codegen is a faithful translator: it turns endpoints into tools, one-to-many, and it's excellent at that. What it does not do is operate the result. The generated server still needs somewhere to run, keys to hand out, rate limits to enforce, usage to meter, and bills to raise — and it inherits your API's shape, including the disambiguation problem from post two if your endpoints are granular. Codegen ends where the gateway concerns begin. Best fit: teams with a strong spec and an existing platform to host and operate what's generated.
Path 2 — Gateway: operate everything, yourself
Full API-management platforms — Azure API Management, Gravitee, and peers — give you the operational layer: auth, keys, rate limiting, versioning, analytics, the works. Azure APIM now documents exposing REST APIs as MCP servers directly, so an existing API behind the gateway can be surfaced to agents with the gateway's policies applied. [3] Gravitee similarly positions itself around agentic and MCP traffic on top of its gateway. If you already run one of these, extending it to MCP is the path of least resistance and most control.
A gateway gives you every knob. The question is not whether it can do the job — it's whether you have the team to turn all those knobs, forever.
The cost is exactly that control. A gateway is powerful and general, which means it is also a substantial thing to configure, secure and keep running. For a large org with a platform team, that's an asset. For a five-person company shipping one product, standing up APIM to expose four tools is using a container ship to cross a pond. Best fit: organizations that already operate gateway infrastructure, or are big enough to justify doing so.
Path 3 — Managed MCP: the layer between
The third path treats "agent-callable API" as its own managed product: you point it at your existing endpoints, and it handles the MCP protocol, the tool descriptions, the keys, the tiers, the rate limits and the metering — without you generating and then operating a server, and without standing up a full gateway. Monetization-focused layers like Moesif and Zuplo pioneered this shape for ordinary APIs — a thin, managed plane for keys, limits and billing on top of infrastructure you already have. [4] A managed MCP layer applies the same idea specifically to the agent surface.
This is the category Make Me An MCP lives in, so read the next line knowing that: it's the fit when you want to be agent-callable in an afternoon and not inherit a gateway to run. You register your platform, bundle your endpoints into task-shaped groups, set tiers and rate limits, and get agent-readable tool descriptions drafted for you from your endpoint signatures — the "yellow pages" an agent reads to decide whether to call you. It is not the right answer for everyone: if you need deep, bespoke gateway policy or you already run APIM at scale, path two gives you more control than any managed layer will.
The fit test, by team size
Strip away the branding and it's mostly a question of who operates what:
- You have a platform team and a gateway already: extend the gateway (path 2), or generate with codegen and run it on your stack (path 1).
- You have a clean spec but no ops appetite: codegen for the artifact, a managed layer to operate it (paths 1 + 3).
- You're small, want to be callable now, and don't want to run infrastructure: managed MCP (path 3).
- Agent access is a product you intend to charge for: whichever path you pick, make sure it includes metering and tiers — codegen alone won't, and that's the subject of the final post.
There's no universally correct choice, only a correct-for-you one. The mistake isn't picking the "wrong" path; it's picking a path without pricing in the operation, and discovering the true cost after you've committed. Next, the piece every path eventually confronts: what it means to actually put a price on a tool call.