I watched a coding agent spend twelve minutes inventing a half-broken Stripe client because someone pointed it at an OpenAPI spec and hoped for the best. Same agent, same afternoon, with an MCP server in the loop: three tool calls, correct pagination, done before the kettle boiled.
That is the whole story, really. MCP isn't another API to call. It's the layer that stops every other API being the agent's problem.
The glue tax
Frontend teams already know the pain. One REST surface for auth, another SDK for billing, a third GraphQL island for product, plus a handful of webhooks that only make sense if you were in the Slack thread when they were invented.
Humans cope by writing adapters and forgetting them. Agents cope by hallucinating adapters every session.
By spring 2026 people had stopped treating MCP as "that Anthropic protocol" and started treating it as what it is for builders: a single conversation shape. Tools, resources, prompts. Discoverable. Typed enough that a TypeScript shop can care. Client talks one protocol. The server decides whether the thing underneath is REST, gRPC, a CLI, or a spreadsheet someone should not have put in production.
)
One protocol, many ugly backends
Your Next.js app does not speak Postgres wire protocol from the browser. It speaks HTTP to a backend that does. Agents should get the same courtesy.
You glue the mess once, behind the server. Every agent client inherits the tidy surface. That is the frontend mindset applied to AI: push complexity behind a contract, keep the consumer boring.
)
What agents actually want
Agents do not want your carefully versioned /v2/users/{id} route. They want verbs that match intent:
MCP lets you name those verbs without pretending they are a public product API. Resources cover the read-heavy stuff (docs, schemas, file trees). Prompts cover the reusable "how we do this here" rituals. Tools cover the actions.
The period-accurate take in April 2026 is not "rewrite everything as MCP". It is "stop teaching every agent your company's private dialect of HTTP".
Frontend people already get this
If you have ever wrapped three payment providers behind one checkout service, you already understand MCP. Same pattern. Different consumer.
The consumer used to be a React form. Now it is also an agent with a short attention span and a dangerous willingness to invent SDKs from memory.
Give it one protocol. Prefer boring tools with sharp names. Keep secrets on the server side. Let the model discover capability instead of reading a 40-page integration guide you wrote in 2022 and never updated.
)
Honest caveats
MCP does not make bad APIs good. It makes bad APIs callable in a consistent way. You still own auth scopes, rate limits, and the question of whether an agent should be allowed to refund_customer at 2am.
Also: a fat MCP server with fifty vaguely named tools is just SOAP with better marketing. Curate. Delete. Prefer a small surface the agent can hold in its head.
Thoughts
Stop wiring agents to the internet one SDK at a time. Give them a backend that speaks MCP, and let the rest of the estate stay as weird as it already is.
&w=3840&q=75)


