"We've set up MCP, so we're agent-ready." That covers your own team's tools. It's a different job from the one a stranger's agent needs done.
MCP is genuinely useful, just not for the case most businesses think it covers. It's strong for an operator's own tools, a chat assistant working against your booking system, less so for a stranger's AI agent trying to book or buy from you. Both are real, but only one of them is what "agent-ready" usually means.
6 min read
What that setup is good at
A hotel group's operations manager sets up an AI assistant that can query the property-management system directly: tonight's occupancy, tomorrow's arrivals, which rooms need turning around. It's genuinely useful, built on the same connection protocol, MCP, that a lot of the industry talk about "agent-readiness" refers to. The team reasonably concludes the box is ticked. It isn't, not for the thing most of that talk is about.
An assistant querying a property-management system directly, or any internal tool, is a real, working use of the same connection layer: an operator's own assistant calling into the operator's own systems. It's backwards-facing in the sense that matters, a member of staff using AI to work faster against tools they already run. That's a genuinely strong use of the technology, and it exists today.
What it doesn't cover
A stranger's agent, working on behalf of a guest who's never dealt with this hotel before, trying to check availability and book a room, needs something different. It needs to prove who it is, prove it's allowed to spend on the guest's behalf, and complete a transaction the hotel can settle, none of which the connection layer alone provides. Having MCP wired up to your own PMS tells you nothing about whether that separate, harder chain is in place.
The two cases, side by side
One is a person on your own team, using an assistant as a better interface to systems you already run. The other is a person who's never heard of you, whose agent needs to arrive, prove itself, get authorised, and complete a purchase, all without a human on your side doing anything by hand. The connection protocol is genuinely shared between both cases. Almost everything else about them isn't. MCP itself isn't a human-shaped tool the way a page or a chat widget is, it's real infrastructure, doing a real job. The mistake here is the same incompleteness behind every other myth in this hub, just from a different angle: one working piece mistaken for the whole system.
Where this shows up for a business
Selfe covers the identity, authorisation and checkout layers a stranger's agent needs, the parts MCP alone was never built to handle, alongside the connection itself. This site's protocols hub, starting with "The plumbing behind every agent purchase," covers each piece properly.
So is MCP a waste of effort?
No, it's genuinely useful for internal tooling. It's just answering a different question than "can a stranger's agent book from us."
What's missing for the consumer case?
Proof of who the agent is, proof it's allowed to spend, and a way to complete the transaction, covered properly in this site's protocols hub.
A lot of what you've heard about agentic commerce isn't quite right.
Every myth in this hub comes from the same mistake: judging the future by how well it fits today's tools, a page, a widget, a chat window, a markup file, instead of asking what would make sense if you were starting clean. The actual destination underneath all of it is simpler than any of the myths: AI agents talking directly to data, not reading pages built for people.
"Just add a chatbot" was never a strategy. Here's the argument for why.
A chat widget is a human-interface metaphor, a text box someone types into, bolted onto a business that hasn't changed underneath. It answers the question "how does a person talk to us" when the real question is whether the facts behind the widget are the ones an AI agent can act on.
"WebMCP is the real answer for autonomous agents." Maybe eventually. Worth asking why it's needed at all.
WebMCP is genuinely early, worth flagging as unsettled rather than treated as decided either way. Even taken on its own terms, it's answering a narrower question than it sounds: how an AI agent copes with a web built for people, not what agentic commerce looks like if nobody had to cope with that at all.
The plumbing behind every agent purchase.
Every purchase an AI agent completes, whatever it's buying, passes through the same four jobs: proving who the agent is, proving what it's allowed to spend, connecting to the business's own systems, and completing a transaction the business can settle. The protocols in this hub each do one of those jobs. None of them does all four.