The Problem
Right now, if you want an AI agent to use a web service say, your bank’s API or a weather service, there’s a protocol called MCP that acts as the middleman. Think of MCP like hiring a full-time translator who sits between your AI and every service it talks to. The translator speaks every language, handles all the formalities, and makes sure both sides understand each other.
That translator is great when the conversation is complicated, but most of the time, you’re not having a complicated conversation, you’re ordering coffee. You don’t need a simultaneous interpreter to order coffee.
The problem is that right now, the translator shows up for every conversation whether you need them or not, and they bring their own desk, their own filing cabinet, and their own phone line. For thousands of web APIs that already speak HTTP (the language the entire internet already runs on) that’s a lot of furniture for a simple interaction.
This isn’t theoretical either, major companies are already saying this out loud: Perplexity, the AI search company, announced they’re moving away from MCP internally because the translator is eating up too much of the AI’s attention span. Other prominent voices in the industry are building simpler alternatives. The people who actually run these systems in production are telling us the overhead has become the problem.
The History Lesson
We’ve seen this movie before. In the early 2000s, web services had a similar middleman problem called SOAP. Every service needed its own formal description document, every consumer needed a special client to read it, and the whole thing was technically correct but practically exhausting.
REST won that battle not by being more powerful, but by being less. It said: “The web already has verbs like GET and POST, it already has addresses, it already has error codes. Why are we building a separate system to describe what the web already does?” And the industry steadily went, “Oh. Right.”
MCP is in a similar spot. Not identical, mind you, as MCP does things REST doesn’t, and I’ll be careful about where this comparison breaks down, but the pattern rhymes.
What I’m Proposing
Instead of hiring a translator for every API your AI talks to, what if each API just wore a name tag?
Not a simple “Hi, my name is Weather API” name tag. A really good one. One that says: “Here’s what I can do. Here’s when you should ask me. Here’s when you shouldn’t. Here’s what credentials you need. Here’s what I’ll give you back. And here’s what to do if something goes wrong.”
That’s the proposal. A standardized JSON file (basically a structured document) that any web service can put at a predictable address on their server. An AI agent hits that address, reads the name tag, and now knows everything it needs to use that service directly. No middleman, translator, or extra infrastructure.
The technical term is a manifest served at /.well-known/ai-capabilities, but the mental model is this: every API gets a really detailed name tag that AI agents know how to read.
The Important Part of the Name Tag
The most important piece of that tag is what I call the intent block. It’s where the people who built the API write down their domain knowledge in a way that an AI can use.
Think of it this way: An API spec today is like a restaurant menu, in that it tells you what dishes are available and what’s in them. The intent block is like having the chef come out and say: “If you like spicy food, order our blackened mahi, don’t order the souffle if you’re in a hurry as it takes 40 minutes, and get the appetizer before the main course because the portions are timed.”
That’s not the AI figuring things out by trial and error. It’s the expert who built the thing telling the AI how to use it well. As far as I’ve found, nobody else has proposed this in quite this structured way, and I think it’s the piece that matters most for making AI agents actually reliable at choosing the right tool at the right time.
What This Doesn’t Do (And Why That’s Okay)
Here’s where I have to be honest, and I think this is actually the part that makes the proposal credible rather than undermining it:
MCP does something genuinely valuable that the name tag doesn’t, it normalizes the conversation. When your AI talks to ten different APIs through MCP, it gets responses back in one consistent format regardless of how each API actually structures its data. That’s like having a translator who not only speaks every language but converts every cuisine into the same plate format so you always know where the fork goes.
My proposal doesn’t do that. Each API still responds in its own format. I’m proposing that a shared software library handles the translation instead of a per-service middleman. That library is a significant piece of engineering (I’m not pretending it’s simple) but the bet is that one good shared library is better than thousands of individual translators.
There are also things MCP handles that this proposal deliberately doesn’t try to touch. Local tools on your computer, including file access, database queries, and IDE integrations aren’t web services. They can’t put a name tag on the internet itself. MCP’s approach to local tooling is the right one, and nothing I’m proposing changes that. The same goes for truly interactive sessions where the AI and the service are having an ongoing back-and-forth conversation, like collaborative editing or live debugging. Those need a persistent connection where a name tag isn’t enough.
Being clear about what you don’t solve is just as important as being clear about what you do. If I claimed this replaces MCP for everything, nobody who actually builds these systems would take it seriously. The claim is narrower and I think stronger for it: for web APIs that already speak HTTP, the discovery and intent layer can be a static document rather than a running protocol.
One more thing worth being upfront about: MCP has gotten lighter to deploy recently. Its newer Streamable HTTP transport means you can run an MCP server as part of your existing web application rather than as a separate process. So the argument here isn’t really about infrastructure overhead anymore as that gap has narrowed. It’s about carrying only the contract you actually need (the right tool for the job instead of the whole toolbox). An MCP server, even a lightweight one, still implements a full runtime protocol with features designed for use cases most HTTP APIs don’t have. The manifest carries exactly the contract an HTTP API needs to express, and nothing more. That’s a different kind of advantage than “less infrastructure,” and I think it’s the more durable one.
Why This Matters Beyond Tech
The broader point isn’t really about MCP versus manifests. It’s about a pattern that repeats across technology: when a new problem emerges, the first solution tends to be comprehensive and heavy because the problem is poorly understood and nobody knows yet which parts are essential and which are ceremony. Once the ecosystem matures and the essential parts become clear, a lighter solution emerges that handles the common case simply and lets the heavy solution focus on the cases that actually need it.
Be it SOAP and REST or monoliths and microservices, the same pattern repeats over and over. MCP is in the comprehensive-and-heavy phase, and this proposal is arguing that the essential parts are now clear enough to separate out.
If MCP itself evolves to include a lightweight, static, HTTP-native path for simple integrations (and their roadmap suggests they’re already heading that direction) then this thesis wins even if the specific format I’m proposing isn’t what gets adopted. The goal is the design direction, not the empire.
What Happens Next
I’m building a reference implementation. That’s the only thing that turns a blog post into something real. A library that API providers can use to serve these manifests, and a client library that AI orchestrators can use to consume them. The client library is the hard part and the part that has to be genuinely good, or the whole thing falls apart.
After that, real-world testing with actual API providers. Then, if it works, formal standards proposals. That’s a multi-year timeline, and I’m being realistic about that rather than pretending this ships next month.
The Technical Deep Dive
This post is the argument. If you want the blueprint with the full manifest schema with working JSON examples, the security model, the temporal behavior patterns for async operations, the Streamable HTTP comparison, and the complete scope boundary analysis of what MCP still owns, checkout out the technical proposal which lives here:
MCP Walked So We Could Run: Technical Proposal →
That piece is written for protocol engineers, distributed systems architects, and anyone who wants to see the schema and poke holes in the specifics. This piece is the mental model, while that one is the spec, but both are part of the same argument.