MCP Is Eating the API Economy

Model Context Protocol is doing to API integration what REST did to SOAP: replacing the hand-written integration layer with something an agent can discover and use on its own.

The first time most senior engineers see an MCP server, they write it off as a wrapper around JSON-RPC. It is. That was also true of REST over HTTP in 2005.

The question MCP actually answers is the one REST answered badly for twenty years: how does one piece of software expose its capabilities to another piece of software that has never seen it before? REST's answer was "read the docs and write a client." That answer only works when the reader is a human developer.

REST APIs were built for humans writing client code. Endpoints, docs, hand-written fetch calls in the right order with the right parameters. Every integration is bespoke.

That works when the consumer is a human developer. It breaks when the consumer is an LLM. An LLM does not read your Swagger file and decide which three of twelve endpoints to chain together. It needs the capability described in its input: tool name, what it does, input schema, output schema, side effects.

MCP gives exactly that shape. A `tools/list` call returns every capability with a JSON schema the model can reason about at inference time. No SDK, no code generation, no onboarding ticket.

The transformative part of MCP is not any single feature. It is runtime composition.

When every service exposes itself as MCP tools, an agent can discover and chain them at inference time. A support agent reads from your CRM, queries your billing service, drafts a Slack message, and files a ticket — using tools it first heard about thirty seconds ago. No hardcoded integrations. No provider-specific middleware.

This is the Unix philosophy applied to agents. Small focused tools that compose. The composer is no longer a shell script; it is a model that can reason about which tools to combine and in what order.

Making it trivially easy to connect agents to arbitrary tools also makes it trivially easy to connect agents to malicious tools. Tool poisoning — where a tool's description promises one behavior and its implementation does another — is the SQL injection of the MCP era.

Most teams shipping MCP servers today are not thinking about this. They are focused on making things work. Every major security crisis in the history of the web started the same way.

The teams that win in the MCP economy will not be the fastest to ship. They will be the ones who figured out tool provenance, output sanitization, and sandboxing before they had to learn it the hard way.

If you build software that other software consumes, you should already be shipping an MCP interface. The economics force it.

A REST integration costs a developer days. An MCP tool costs minutes. When integration gets 100x cheaper, you do not get 100x more integrations of the same thing — you get entire categories of integration that were never worth building before. Stripe already ships an MCP server. So does Linear. So does Supabase.

Every SaaS will eventually expose MCP tools. Every internal service will have an MCP interface. The only real question is whether you ship one before your competitor does.