OpenAPI or MCP? What each one is actually for

You already publish an OpenAPI document. Someone on the team has read about MCP and wants to know whether the next two weeks go into standing up a server, or whether the spec you have is enough. It is a reasonable question with a genuinely unsatisfying answer, which is why so much has been written about it.

Most of that writing compares OpenAPI vs MCP for LLM tools on one axis: how the tool definitions get in front of the model. That axis is real, it is well covered, and by now it is close to settled. What has changed recently is that MCP acquired an opinion about something else — what the answer looks like when it comes back — and that second axis is barely written about at all. If your OpenAPI spec is already the integration, it is the one that decides your answer.

The short version

Pick OpenAPI if the tools are your own API, consumed by your own assistant, and the list of operations changes at the speed your backend does. You already have the document. Adding a protocol between it and your model buys you nothing you need.

Pick MCP if several hosts you do not control need the same tools, or if you want your capability to show up inside somebody else's assistant. Discovery, negotiation and distribution are what it is for, and they are real problems that OpenAPI does not address.

They are not alternatives at the bottom. Both end as a JSON schema in a prompt. The choice is about who assembles that list, how it is delivered, and — increasingly — whose screen the result is drawn on.

What OpenAPI is

A description of an HTTP API that already exists. Paths, operations, parameters, request bodies, response schemas, auth. It was designed for documentation, client generation and testing, and it predates any of this by a decade.

For tool use, the mapping is mechanical: operationId becomes the tool name, parameters become the arguments schema, and the model fills it in. Half a dozen libraries do this in a line of code. Bin Wang's widely-cited experiment makes the case that it is sufficient — under 300 lines, using structured output rather than a provider's tool-calling API, and portable across models as a result. Checked 21 August 2026.

The honest limitation is the one Christian Posta names: an endpoint is not a tool. A human integrating your API fills in the semantic gaps from context, and a model cannot. His prescription is unique, action-oriented names, purpose explanations, examples and preconditions — none of which a typical spec contains, because it was written for a reader who already knows what the product does. Checked 21 August 2026.

That criticism lands. It is also an argument about description quality, not about protocol, and it applies just as hard to a hand-written MCP server as to a converted spec.

What MCP is

A protocol for exposing capabilities to a model host: tools, plus prompts and resources, plus the transport and the handshake that let a host discover what a server offers at runtime. It solves a distribution problem. Your API describes what exists; MCP describes how a host that has never heard of you finds out.

The mechanical conversion path is well-trodden and heavily used. FastMCP will turn a spec into a server, and its default is worth knowing: "By default, FastMCP converts every endpoint in your OpenAPI specification into an MCP Tool" — mutating verbs included — with filtering available through ordered RouteMap objects. Checked 21 August 2026. Vendors in this space are consistent that auto-converted servers underperform curated ones, which is Posta's point restated as a product.

MCP also evolves through a public SEP process, which matters here: it means the protocol's opinions are dated and citable rather than a matter of interpretation.

What they share

More than the framing usually admits, and this is the part that stops the argument being useful.

Both end in the same place. A list of named functions with JSON Schema arguments, serialized into a prompt. The model does not know which protocol delivered them.

Both leave safety to you. Neither format has a concept of a read-only operation. OpenAPI has verbs, which are a convention rather than a guarantee; MCP has tools, which are whatever the server says they are. If a mutating operation is reachable, that is a decision someone's configuration made — which is why keeping mutating verbs disabled by default is the same work regardless of which one you picked.

Both need description quality that specs rarely have. The summary field written for a developer portal is usually the wrong length and the wrong altitude for a model.

So if someone tells you MCP is more secure than OpenAPI, or the reverse, they are describing two implementations rather than two protocols.

Axis one: who assembles the tool list

This is the axis everything else on this SERP argues about, and the framing everyone lands on is static binding versus runtime discovery.

With a spec, you bind statically. Your assistant reads a document you control and builds its tool list from it. Adding a tool is a config change on your side. Nothing is negotiated, nothing is discovered, and the set of things the model can do is knowable by reading a file.

With MCP, the host asks at runtime. A client queries the server for capabilities, so new tools become available without changes to the client. That is the whole value when the client is not yours — and a mild liability when it is, because "the tool list changed and nothing was deployed" is a harder thing to reason about during an incident.

If you own both ends, runtime discovery is solving a problem you do not have. If you do not own both ends, it is the only thing that works.

That is genuinely most of the decision, and it is why the debate has stayed civil: both sides are right about different deployments.

Axis two: whose surface the answer appears in

Here is the part that has changed and that the comparisons have not caught up with.

MCP now specifies a user interface. SEP-1865, "MCP Apps", reached Final status on the Extensions Track (created 21 November 2025; checked 21 August 2026). Servers predeclare UI resources under a ui:// scheme, tools reference them through metadata, and the host renders them. The initial content type is text/html;profile=mcp-app, and the security model is mandatory iframe sandboxing, with predeclared templates hosts can review, JSON-RPC messages that can be logged, and optional user consent for UI-initiated calls. The SEP's own rationale for going HTML-first names "simplest security model (standard iframe sandbox)" among its reasons.

That is a coherent design, and for its target it is the right one. When your capability has to render inside ChatGPT, Claude, VS Code or Goose, HTML in a sandbox is the only thing that could possibly work: the host cannot compile your components, and it must contain whatever you send.

It also decides two things that matter if the surface is your own app.

The UI is a web document. Sandboxed, styled by whoever authored it, and rendered in a frame. Inside a host that is a feature. Inside a native app it is a WebView with your brand's fonts loaded twice, its own scroll behaviour, and a set of accessibility affordances that are not the platform's. That trade-off is the same one behind rendering generated UI in Swift rather than in a web view, and neither answer is universally correct.

The answer lives in the host's surface, not yours. This is the strategic half. If your assistant's best work happens inside someone else's client, the relationship, the context and the next tap belong to that client. For a tool vendor, that is distribution. For a consumer app whose customers already opened your app to ask, it is the opposite of what you wanted.

The third option — a spec, read by your own assistant, rendering native components inside your own app — is not on this SERP at all, because the debate has been about tool delivery rather than about answer delivery. It is the shape Uzori takes, and its trade is explicit. No distribution into other hosts and no HTML. In exchange the model emits records from a fixed contract of 23 types with no colour, font, spacing or tree field anywhere in it, rendered by components your team already ships.

OpenAPI vs MCP for LLM tools: how to choose

Three questions, in this order.

1. Who is the host? If it is somebody else's assistant, you need MCP, and the rest of this is academic. If it is yours, you do not, and the spec you already publish is the shorter path.
2. Who needs to see the answer, and where? In a chat client, MCP Apps is now the standard way to make it more than text. In your own product, HTML in a frame is a cost rather than a feature, and native components are available to you in a way they are not to a general-purpose host.
3. How often does the tool list change without a deploy? If the answer is "never, it is in our config," runtime discovery is machinery you will maintain and not use.

And the answer that is often correct: both, for different surfaces. An MCP server so your capability is reachable from general assistants, and a direct spec-driven path inside your own app where you control the rendering. They are not competing for the same slot, and treating the choice as exclusive is the mistake this comparison usually encourages.

Frequently asked questions

Do I need an MCP server if I already have an OpenAPI spec?

Not to make your API callable by your own assistant. A spec already describes operations that exist, and turning it into tool definitions is a short piece of code. You need MCP when a host you do not control has to discover those tools, which is a distribution problem rather than an integration one.

Is MCP just OpenAPI with extra steps?

For the narrow case of one client calling one API, close to it. MCP adds runtime discovery, capability negotiation, prompts and resources, and — since SEP-1865 — a UI extension. Those are worth the steps when a host is not yours and cannot be told about your API in advance, and they are overhead when it is.

Can MCP render a user interface?

Yes, as of SEP-1865, which reached Final status on the Extensions Track. Servers predeclare ui:// resources containing HTML, tools point at them, and the host renders that HTML in a mandatorily sandboxed iframe. It is an optional extension that clients and servers negotiate, so support varies by host.

Which should I pick for an assistant inside my own app?

Read your spec directly, unless something else needs those tools too. You control both ends, so discovery buys nothing, and the rendering question flips: inside your own app you can draw native components instead of framing a web document, which is the whole reason the customer opened your app rather than a chat client.

Where to start

Answer question one honestly, because it collapses the other two. If the host is yours, spend the two weeks on the parts this comparison does not cover: which operations belong on the allowlist, what your response schemas can actually support, and what happens on screen when the model gets something wrong.

If you want to see what the third option looks like in practice — a spec, an allowlist, and native components rather than framed HTML — the contract and the integration format are short enough to read in one sitting. Ask for them at hello@uzori.ai.