JIMDRURY.
Jim Drury
Flat blue editorial illustration: on the left an agent pointed at openapi.json scribbles a tangled invented SDK; on the right the same agent makes three clean tool calls to an MCP server (stripe.list_charges, stripe.next_page, stripe.summarise).
agents

Stop hand-gluing REST. MCP is the AI backend now.

4 MIN READ

I watched a coding agent spend twelve minutes inventing a half-broken Stripe client because someone pointed it at OpenAPI and hoped for the best.

Same agent, same afternoon, MCP server in the loop: three tool calls, correct pagination, done before the kettle boiled.

I laughed. Then I got slightly annoyed I'd spent so long watching the first one fail so confidently.

Confession

I'd been the person who said "just give it the OpenAPI" more than once. It feels responsible. It isnt always.

The glue tax

Frontend teams already know this pain. One REST surface for auth, another SDK for billing, a third GraphQL island for product, plus 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. Different failure mode, same tax.

By spring 2026 people had mostly stopped treating MCP as "that Anthropic protocol" and started treating it as a single conversation surface. There are tools for actions, resources for the read-heavy stuff, and prompts for the how-we-do-this-here processes. Discoverable. Typed enough that a TypeScript dev house can care. The client talks one protocol. The server decides whether the thing underneath is a REST API, a gRPC service, a CLI, or a spreadsheet someone should not have put in production.

Image Preview

Flat blue line illustration: four mismatched sockets labelled REST /auth, billing SDK, GraphQL and webhooks, each with its own glue adapter and zigzag cable down to an agent that rewrites every adapter every session.

The glue tax

The glue tax

One protocol, many ugly backends

Your Next.js app doesnt speak Postgres wire protocol from the browser. It speaks HTTP to a backend that does. Agents should get the same courtesy.

MCP in the middle

Scroll or pinch to zoom. Drag to pan. Use the zoom in, zoom out, and fit buttons to adjust the view from the keyboard.

flowchart LR
  clients["Cursor / Claude Code / custom UI"]
  mcp["your-mcp-server\njira.list · figma.get · gitlab.ci"]
  jira["Jira API"]
  figma["Figma REST"]
  gitlab["GitLab CLI"]
  clients -->|"MCP"| mcp
  mcp -->|"results"| clients
  mcp --> jira
  mcp --> figma
  mcp --> gitlab

Rendering diagram…

You glue the mess once, behind the server and every agent client inherits the tidy surface. That's a frontend mindset applied to AI: abstract the complexity behind a contract and keep the consumer boring.

Image Preview

Flat blue line illustration: a tidy your-mcp-server window with jira.list, figma.get and gitlab.ci fans out to a REST API, a gRPC service, a CLI and a spreadsheet, with the caption glue the mess once, behind the server.

One protocol, many ugly backends

One protocol, many ugly backends

What agents actually want

Agents dont want your carefully versioned /v2/users/{id} route. They want verbs that match intent:

  • get_failing_pipeline

  • open_preview_and_screenshot

  • search_design_tokens

An MCP lets you name those verbs without pretending they're a public product API. Resources cover the read-heavy stuff. Prompts cover the "how we do this here" processes. Tools cover the actions.

The April take, for me, isnt "rewrite everything as MCP". It's stop teaching every agent your company's private dialect of HTTP.

Frontend people already get this

If you've 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's 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.

Image Preview

Flat blue line illustration comparing two diagrams: a React form calling a checkout service that wraps Stripe, PayPal and Klarna, and an agent calling an MCP server that wraps get_failing_pipeline, search_design_tokens and open_preview.

Frontend people already get this

Frontend people already get this

Honest caveats

MCP doesnt make bad APIs good. It makes bad APIs callable in a consistent way. You still own auth scopes, rate limits, and 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.

I've watched teams ship the fat version. Cleaning it up later is miserable.

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.

Similar Articles