--- published: true layout: post title: MCP Is Last-Mile Plumbing image: https://kinlane-images.s3.amazonaws.com/apievangelist/api-evangelist-images/mcp-is-last-mile-plumbing.png date: 2026-08-04 author: Kin Lane tags: - MCP - Agents - AI - APIs - API Design - Governance - Strategy --- I have been trying to find the cleanest way to say something about [Model Context Protocol](https://modelcontextprotocol.io) for months, and it finally boiled down to a single sentence I cannot stop repeating to people: *MCP is the one last thing that lets an LLM talk to the thing — but everything else, please still build a REST or GraphQL API.* That is the whole sentence, and I think it is the clearest thing I have managed to say about MCP all year. I have been writing about this protocol for months, from [how I actually use MCP across API Evangelist](https://apievangelist.com/2026/07/22/how-i-actually-use-mcp-across-api-evangelist/) to [MCP discovery and governance](https://apievangelist.com/2026/06/19/mcp-discovery-and-governance/), watching every vendor now lead with an MCP server the way they used to lead with a mobile SDK, and that one sentence puts a frame around all of it. Here is the frame I keep coming back to. Think about how water actually gets to your kitchen. There is a reservoir, which is your data. There is a treatment plant, which is your business logic — the messy, regulated, expensive work of making the raw thing safe and usable. There are the water mains that run under the street, which are your APIs, the durable public contract that everyone in the neighborhood shares. And then there is the last few feet of pipe that come up through your floor and connect to the faucet. That last stretch of pipe is MCP. It is genuinely necessary — without it the water never reaches the tap, and right now the tap is an LLM. But nobody in their right mind celebrates the last few feet of pipe as though it were the water system. You do not put the flexible supply line under the faucet on the front of your annual report. Yet that is more or less what a lot of companies are doing in 2026. The mistake is not building MCP servers. I build them, I like them, and I think agents talking to your capabilities through a well-described interface is one of the better things to happen to APIs in a while. The mistake is mistaking the connector for the infrastructure. When you skip the reservoir, the treatment plant, and the mains, and you just run a flexible hose straight from the LLM into whatever happens to be lying around, you have not shipped an API strategy. You have shipped a garden hose and called it municipal water. It works for exactly one consumer — the agent that happens to be plugged in this quarter — and it works only as long as that consumer, that runtime, and that protocol stay fashionable. None of those three things have a track record of staying fashionable. This is the part that gets lost in the excitement. An MCP server is a single consumer surface. It is the agent's faucet. A REST or GraphQL API is the mains — it serves the agent's faucet, and the mobile app's faucet, and the partner integration's faucet, and the internal service's faucet, and the reporting job that has been quietly running since 2019. When you build the API first, the MCP server is a couple of days of work sitting on top of something real. When you build the MCP server first and nothing underneath it, you have created a capability that exactly one kind of client can reach, with no versioning story, no deterministic contract, no reuse, and no way for anyone to build against it who is not currently holding a language model. You have traded away every consumer you cannot see for the one consumer that is trending. And the trending consumer is the least stable one you have ever designed for. A REST contract I published in 2015 still works. The mains under the street outlast the house. But the last-mile connector into an LLM is riding a protocol that is barely two years old, wired to model behavior that changes with every release, inside a tooling ecosystem that reinvents itself every few months. That is fine — that is what the last mile is supposed to be. The last mile is allowed to be cheap, swappable, and slightly disposable, precisely because everything upstream of it is not. The flexible supply line under your sink is designed to be replaced. The water main is not. If you build your whole strategy out of flexible supply line, you have built a strategy designed to be replaced. There is a governance dimension here too, and it is the one I care about most. When your MCP server is a thin, honest projection of a real API, governance is something you already did upstream — in the [OpenAPI that is the unit of governance](https://apievangelist.com/2026/06/25/openapi-is-the-unit-of-governance/), in the contracts and the linting and the [decisions about what agents are even allowed to consume](https://apievangelist.com/2026/07/24/governing-what-agents-are-allowed-to-consume/). The MCP server inherits all of it. When your MCP server is the whole thing, there is nothing upstream to inherit from, and governance becomes a scramble to bolt policy onto a hose after the water is already flowing. I have watched enough teams try to retrofit governance onto an ungoverned surface to know how that ends, which is why I keep saying [there is no platform for API governance](https://apievangelist.com/2026/07/20/there-is-no-platform-for-api-governance/) that saves you from not having built the foundation. So the pitch is not anti-MCP. I ship MCP servers for [API Evangelist and APIs.io](https://apis.io) because the last mile matters and I want agents to reach my work through a clean interface. But behind every one of those servers is a real, versioned, documented API that a human or a machine can consume without an agent in the loop at all. The MCP server is the faucet. The API is the mains. Build the mains. Treat the water. Own the reservoir. Then, by all means, run the last few feet of pipe up into whatever the agent of the month happens to be — and when that agent goes out of fashion, you will still have everything that actually mattered, and you will be able to run a new hose in an afternoon. That is the whole argument, and the one sentence says it better than the whole essay does. MCP is the one last thing that lets an LLM talk to the thing. Everything else, please, still build a real API.