APIs Are Service Contracts, MCPs Are Intent Contracts

There’s a tidy story going around about how the agent ecosystem will shake out. Every SaaS vendor will build and own its MCP server, the way every vendor today ships an API, and the map of MCPs will end up looking like the map of vendors we already know.

It’s a clean story. It’s also wrong. And getting it wrong leads teams to build the slow, expensive, error-prone agents we keep seeing fail in production.

APIs and MCPs live at different layers. Once you see that, the one-to-one vendor map falls apart.

An API is a service contract

Take the technical jargon out and an API is a service contract. It tells a developer how a system works and how to interact with it. The Gmail API explains Gmail: there are messages, there are threads, there are labels, and here are the operations you can run against them. Create, read, update, delete (four operations that are commonly referred to as CRUD by developers) are repeated across every object the product exposes.

That model is great for describing a service. Almost every API in existence is some combination of resources and CRUD operations, and that’s exactly what you want when the job is to define how the underlying system behaves.

Most MCP servers on the market today are just that API wrapped in natural language and relabeled. Technically, it speaks the protocol, so technically it’s an MCP server. It’s also usually a bad one. You can see this play out at scale on public MCP benchmarks, where the wrappers consistently score at the bottom. Wrapping CRUD in plain English doesn’t change what layer you’re operating at. It just moves the same resource map one step closer to the model and hopes the agent figures out the rest.

An MCP is an intent contract

A great MCP server is the inverse of an API. It isn’t organized around what a system can do. It’s organized around what someone is trying to accomplish. That’s why MCP servers consume APIs in the first place. The service contract is the building block. The intent contract is what you build on top of it.

Here’s what that looks like in practice. Say you’re building an agent for your sales team. A rep is about to walk into an account, hits a button, and the agent assembles a one-page brief: what to talk about, what to propose, what context matters. To do it, the agent reads email, pulls from the CRM, and grabs the right brochure. Those brochures live in Google Drive, in a subfolder of a subfolder.

Now, point a generic Google Drive MCP server at that task and watch what the agent has to do. It opens Drive. It lists folders. It reasons about which folder leads to brochures. It navigates in. It opens files, reads them, and tries to decide which brochure fits the account. Every one of those is a separate agent turn. Each turn adds latency, burns tokens, and creates another chance for the agent to take a wrong turn and grab the wrong file.

The agent can do it. It just does it slowly, expensively, and with compounding odds of a mistake.

For the sales agent, though, we already know the intent. We are trying to find the right brochure. So the right tool isn’t “browse Drive.” It’s get_brochure. That tool carries its own workflow. It goes straight to the brochure folder, runs a known method for matching the account to the right file, and returns it. It might call the Drive API or the Gmail API under the hood, but the agent never sees that. It asked for a brochure and got a brochure.

Line the two up and get_brochure wins on every axis that matters in production: faster, far fewer tokens, and a higher accuracy rate because there are fewer places to go wrong.

MCPs map to intents, not vendors

This is where the vendor map breaks. get_brochure isn’t a Google Drive tool, even though it touches Drive. It’s a sales tool. It might pull from Drive, the CRM, and email inside a single workflow. It exists because of what the sales team is trying to do, not because of which vendor stores the file.

So MCPs don’t map one-to-one to vendors. They map to intents. One useful MCP server often spans several vendors’ APIs, and one vendor’s API shows up inside dozens of different intent-based tools, each shaped by a different job. The unit of design is the use case, not the system of record.

That’s also why “every vendor owns its MCP” thinking misreads the problem. A vendor can ship a faithful service contract for its own product. It can’t ship the intent contract for your sales workflow, because that intent lives in your business, spans the systems you chose, and changes as your work changes.

This distinction is the one most API gateway approaches miss. A gateway sits at the service-contract layer. It routes, authenticates, and rate-limits calls to systems. Useful work, but it leaves the agent to do the rest: turning intent into the right sequence of calls across systems, reliably, every time.

That gap is the layer we built Arcade.dev to own. The tools in our catalog are designed as intent contracts, not API wrappers, and every one is evaluated against the real task an agent performs rather than whether the underlying call merely succeeds. When a user says “make the intro paragraph friendlier,” Arcade resolves it to the exact segment and text. The agent never has to think beyond the intent. And when your intent is specific to your business, you author your own tools and ship them on your own timeline, right alongside the thousands of LLM-optimized tools we’ve already built.

The vendors aren’t going to hand you that layer. The intent is yours.