Blog

It Was Never APIs or MCP. It's REST APIs or MCP APIs.

Jerome Louvel ·August 20, 2026

Table of contents

Every few years the same headline returns, with the nouns swapped. Has REST killed SOAP? Has GraphQL killed REST? Has MCP killed APIs?

The answer is always no, and by now that much is well covered: MCP sits on top of your APIs, the two operate at different layers. Correct — and one layer short of the interesting part. Why does the question keep being asked, and what does asking it cost us?

The obituary framing is not merely inaccurate, it is expensive. It masks the real evolution, because “X killed Y” announces a winner without saying what changed. And it discards the lessons, because a protocol presented as a clean break invites you to re-learn what its predecessor knew: SOAP’s registries, REST’s caching, GraphQL’s introspection have each been re-solved, at cost, by a successor framed as a replacement rather than a descendant.

So MCP is not what replaces APIs. It is an API protocol — the fifth answer to a set of questions that has not changed since 1999. Two people already said the first half of this: in MCP Is Just an API, Emmanuel Paraskakis calls MCP “another iteration of APIs… by all definitions an API,” and Bruno Pedro names the mechanism — “MCP is in fact JSON-RPC, which is one of many possible styles of APIs.” The question is what follows from it.

Four questions, six answers

Every protocol in this lineage answers the same four questions. Only the last answer changes much.

Read the bottom row and the pattern is obvious: what changes between generations is not the technology but the consumer. SOAP was shaped by the first wave of B2B e-commerce — purchase orders and invoices crossing company boundaries — which is why it inherited CORBA’s remote-object thinking and dragged RPC onto HTTP, HTTP being the one port a firewall would let through. REST was shaped by browsers and phones, gRPC by datacentre latency budgets, MCP by a probabilistic model reading descriptions and picking one.

A vocabulary note that matters more than it looks: the SOAP generation did not call these things APIs. They were Web Services. “API” is far older — it meant the entry points of a local subroutine library long before anything was called remotely — but “Web API” is REST-era vocabulary, the moment the term was borrowed from local computing and stretched across a network. So “APIs” is not a neutral, timeless category here. It is one generation’s answer wearing a much older word, which is part of why APIs or MCP sounds like a coherent question and isn’t.

A fifth question hides in that bottom row: what is the unit of interaction? Resource, query, method, tool, task. A model wants a function to call; an agent delegating work wants something longer-lived — which is why A2A has task states and push notifications and MCP does not.

The description axis is where the progress is

Of the four, one shows real movement: how an API tells you what it can do.

WSDL and OpenAPI are out-of-band — separate artifacts you must locate, version-match and trust, with nothing in an HTTP response to tell you the document has drifted from the implementation. GraphQL broke that in 2015: introspection is mandatory and served by the running server, so __schema cannot lie, because it is the implementation answering. gRPC reflection does the same for protobuf. MCP’s tools/list is the same idea again, nine years later — worth saying plainly, because in-band description is regularly presented as an MCP invention. It is a good idea that took three protocols to become the default.

That is where the lineage genuinely accumulates. The rest is mostly rotation.

The pendulum, not the ladder

It is tempting to read the diagram as a ladder where each rung improves on the last. It is closer to a pendulum.

The 2000s spent considerable energy arguing that RPC over HTTP was the wrong shape — half the case against SOAP, which had carried CORBA’s method-call model onto the web. REST won that argument. Then MCP arrived, and tools/call is a method name and a params object: RPC, back where it started, with the objection dropped rather than answered. Pedro’s “MCP is in fact JSON-RPC” deserves its dates attached, because the dates are the argument. JSON-RPC 2.0 was ratified in 2010, and its ancestor XML-RPC dates to 1998 — the same year the CORBA-to-HTTP work that became SOAP was underway. XML-RPC and SOAP are siblings, not opposites: Dave Winer’s minimal version and the committee’s maximal one, same moment, same idea. The AI era’s flagship protocol runs on the surviving twin of the thing REST was defined against.

Worth clearing up, since the two get conflated: MCP’s 2026-07-28 revision removed the session, not the envelope. It dropped the initialize handshake and the session header; it is still JSON-RPC 2.0, and a server receiving anything else rejects it. Stateless does not mean not-RPC. Discovery has swung too — UDDI registries, then API portals, now MCP registries, the same problem on its third attempt, each begun as though the previous two had not happened.

We have already run this argument once

Of the obituaries at the top, one is recent enough to check the outcome. 2016 to 2018 was wall-to-wall “REST is dead, GraphQL won.” Both survived, usually inside the same company and often over the same data, because they answered to different consumers: the mobile team wanted to pick its response shape, the partner integration wanted a stable versioned contract.

Note what the obituary cost. Framed as REST’s successor rather than its sibling, GraphQL shipped without HTTP caching — a property REST had by construction — and the ecosystem spent years rebuilding it with persisted queries, CDNs and normalized client caches. The lesson was available in the protocol it was declared to have killed.

Nobody asked whether to have “APIs or gRPC” either. They asked whether this service needed a gRPC interface as well as a REST one. That is the question to ask about MCP. It multiplies interfaces; it does not replace them.

Which leaves you maintaining several front doors

A REST API for the web app, maybe gRPC internally, now MCP for the agents, and A2A behind that if other agents start delegating work to yours. The part worth dwelling on is not the count but that the same business operation ends up described four times, in four artifacts — each with its own auth, error mapping, name for the thing, and drift rate, maintained by whoever last needed that front door. Nobody decided to have four definitions of “create invoice.” It happened one reasonable protocol decision at a time.

A2A already drew the right conclusion

The most interesting thing published on this subject this year is not an argument but a spec — and it is oddly absent from the debate, given that it settles it.

A2A reached v1.0 under the Linux Foundation shipping three protocol bindings — JSON-RPC 2.0, gRPC and HTTP+JSON — with formally specified equivalence guarantees between them. preferredTransport and additionalInterfaces were consolidated into one supportedInterfaces[] array, each entry carrying its own url, protocolBinding and protocolVersion, and a2a.proto was promoted from a gRPC implementation detail to what the spec calls the universal, normative source of truth.

That is not a claim that one binding won, and it is not a layering diagram. It is a working group answering the recurring question structurally: stop picking, and stop stacking — describe the thing once and project it. The contract is the durable artifact; the protocol is a projection of it.

One artifact, several protocols

This is the shape an Ikanos capability has always had. A capability declares what it consumes once, then lists what it exposes — rest and mcp side by side in the same file, from the same underlying operations. The same supportedInterfaces[] idea, in the artifact rather than the runtime. ikanos import openapi turns an existing OpenAPI 3.x or Swagger 2.0 document into a capability’s consumes block; ikanos export openapi emits OpenAPI back out of its REST adapter. One file, already fluent in two protocol generations.

Paraskakis reports the same thing from the field — “I use MCP with OpenAPI all the time… if you have really good OpenAPI, you can produce a really good MCP server.” Agreed, with one amendment: if the OpenAPI document is doing that work, make it an input to a declared artifact rather than something you hand-translate each time. His other observation is the warning worth heeding — MCP is “like USB-C, but maybe USB-C in 2015,” where the connector was agreed and what went over the wire was not. A spec changing faster than adoption is exactly the case for keeping your operations in a file the protocol is generated from. Ikanos serves 2026-07-28 today and no capability file changed to get it, because the spec never mentioned sessions or headers.

Stated precisely, since roadmaps and shipped code deserve different verbs: rest, mcp, skill and control are the exposure adapters today, and http is the one consumption adapter. Native gRPC and A2A adapters are proposed, not shipped — and when they land they are new entries under the same consumes / aggregates / exposes model, which is the useful signal that the model was drawn at the right level.

The takeaway

Protocols are how an API meets a particular kind of consumer. SOAP met the trading partner, back when we called it a Web Service. REST met the browser, and borrowed a word from local computing to coin the Web API. gRPC met the datacentre. MCP meets the model, and A2A meets the agent behind it. Each describes its functions, serializes its data, picks an HTTP version, and gets shaped by whoever is calling. The consumer changes; the four questions do not.

So the useful answer is not that MCP complements your APIs, true though that is. It is that a sixth protocol will arrive for a seventh kind of consumer, it will be declared to have killed the fifth, and the teams that suffer least will be the ones who wrote the operation down once and treated every protocol as a projection of it.

Describe it once. Project it as many times as you need.

Subscribe to the Naftiko Manifest

Want to learn more and stay up to date on the latest from Naftiko? Get new posts, releases, and signals from the capability fleet in your inbox.