Model Context Protocol won. It’s now “the boring infrastructure layer” — 78% of enterprise AI teams run MCP-backed agents in production, and it just got its biggest update ever, a fully stateless rewrite meant for “really big players” with tens of thousands of agents.

So the question a solo builder faces is pointed: if the protocol is the standard, why would I ever write a raw API call myself?

The instinct to just grab the API is right more often than the hype suggests. Here’s the rule.

The two decisions you’re actually making

People collapse “API vs MCP” into one question when it’s really two:

  1. Transport — how bytes get from your agent to the capability.
  2. Guardrails — what your agent is allowed to do.

MCP does not make your agent safer. The “stop it from deleting all my Drive files” property lives in the authorization scope you grant and the tool surface you expose — not in the protocol. A raw API call with a tightly-scoped token enforces that just as well as an MCP server that only exposes read tools.

So the safety argument for MCP is a non-argument. What MCP actually buys you is uniformity — the agent and every client talk to every tool the same way. That’s valuable, but only sometimes.

The rule

Use the raw API, tightly scoped, when:

  • You are one agent with a handful of resources.
  • You’re the only consumer, and you’ll stay the only consumer.
  • The guardrail is just scoping a token — trivial to do yourself.
  • You want the provider’s full native surface, not a translation layer.

Use MCP when:

  • Multiple clients or multiple agents need the same resource.
  • You want to swap the model or provider without rewriting call logic.
  • A mature server already exists for something gnarly (auth flows, streaming, pagination edges).
  • You’re composing many tools and want one calling convention.

Why this matters most to the solo builder

MCP’s headline value is an N×M → N+M collapse: instead of one custom integration per (client, resource) pair, you build one server per resource. That payoff only exists when N and M are large.

A solo builder is N=1. You are one agent talking to a few APIs. The collapse doesn’t pay — you’re just adding a translation layer on top of a provider whose native entitlements already do the guardrail work. Fewer layers means fewer things to break, and fewer dependencies means fewer migration headaches when a spec (like MCP’s stateless rewrite) shifts underneath you.

The tiebreaker isn’t “because MCP.” It’s: will a second consumer ever need this resource? If no, the lean call is the raw API. If yes, the uniformity starts to pay for itself.

Sources

  • Agentic AI Foundation — The 2026 MCP Roadmap (2026): transport scalability, agent communication, governance, enterprise readiness.
  • VentureBeat — MCP just got its biggest update ever (Michael Nuñez, 2026): stateless architecture, OAuth hardening, 12-month deprecation policy, MCP Apps/Tasks graduating to official extensions.
  • a2a-mcp.org — MCP 2026 Roadmap (2026): four priorities for enterprise readiness; the N×M → N+M integration-collapse framing.
  • Linux Foundation / Agentic AI Foundation adoption reporting (2026): 78% of enterprise AI teams with MCP in production; ~9,400 public servers.