MCP is the API design we owed humans first
The rush to wrap cloud and platform APIs in MCP servers is mostly intent-based API design Kubernetes showed us years ago, and a platform that needs an agent wrapper was already too chatty for people.
You have to call like seven APIs to get a VM in the cloud. Create a VM, a network, a storage device connected to a VPC and then attach credentials. That’s not intent based. I want a VM.
If you’ve ever provisioned a machine by hand, you’ll recognize this as a tedious series of steps. If you give an agent a bunch of raw calls like this, it’ll turn into a mess like a newcomer-on-day-one would make.
Kubernetes does the exact same thing. When you say give me an ingress or a service in Kubernetes, that reflects out to seven calls too, to create load balancers, SSL certificates, DNS setup.
The Kubernetes Service is a nice example of this outcome-declaring design. You declare the outcome you want (“give me a stable endpoint in front of this set of Pods”) and if you want a LoadBalancer, your cloud provider will build you a load balancer, and the controllers will take care of fanning out. (If you want to read the origin history of this, there’s a long discussion on The Pragmatic Engineer)
The fundamentals of this isn’t everything is going to change because of MCP. What the hell? A whole conference, guys? This is just API design.
The MCP specification defines the tools an agent can discover and call, which is useful plumbing. But it doesn’t help you design better tools. If you have a chatty API, putting it in MCP just gives it a new front door.
So what? Create VM v1, create VM v2, who cares? Because these are intent based APIs. So I think these new tools are reminding us of this.
People spend years arguing about the style of an API, but in the end most of it doesn’t matter as much as “does this call actually do what the caller wants?” Versioning can be solved. An agent guessing seven steps behind a VM is going to get some wrong. So is every engineer working from the same reference docs.
I’m watching people write these huge markdown files to give the agent context. How about you write documentation to give me context so I can have fully working examples.
Say the platform team exposes a single “give me an environment” call.. the agent and the engineer both use it. No wrapper. If my internal platform requires an agent to wrap it and a markdown file to use it, what does that say about the golden path I’m giving my own engineers?