WebMCP is the part that changes things

Almost everything sold as AI readiness is about being read. Publish structured data, publish an llms.txt, publish a clean sitemap, and hope that when an assistant is asked about you, it has something accurate to repeat.

That is worth doing. It is also the least interesting half of the problem, because a business that can only be read is a business an agent can only describe. The customer still has to leave the conversation, find your site, and start again.

WebMCP is the other half. It lets your own pages hand an agent a set of tools, and the agent uses them on the page the person is looking at.

The distinction, without the acronym soup

MCP is off-site. Your business exposes an endpoint, and an assistant calls it from inside ChatGPT or Claude without ever visiting your website. Excellent for reach. The person never sees your brand, your photography or your layout.

WebMCP is on-site. The tools live in the page. The agent searches your catalog, checks a real availability, works out a real price, and the screen the customer is looking at moves while it happens. It is the only one of these protocols where the person can watch the agent work and take the wheel mid-task.

Agent to agent is business to business, and it is early. Their procurement agent talks to your sales agent. Almost nobody needs it this year. It will be cheap to be early on and expensive to be late.

You want all three, but they are not the same product, and only one of them lets the agent finish something in front of the customer.

What “finish something” means

A read-only layer answers “do they have it”. A tool layer answers “book it”.

The gap between those is where every business loses the customer: the moment the conversation ends and a form begins. If an assistant can check the real slot, quote the real price with the real conditions attached, and put a request in front of the person to confirm, the conversation never breaks.

That last clause matters more than the rest of the paragraph. The tools that reach a human should not be able to complete on their own. They should fill the request in, show it, and stop. The agent does the work; the person keeps the decision. Anything else is a machine sending messages to strangers on your behalf, which is a category of software nobody has yet been glad they bought.

The awkward part: you probably cannot ship this to your own website

WebMCP is JavaScript on your pages. Which means the honest first question is not “should we do this”, it is “who can put code on our website this month”.

For a large share of businesses the answer is: a third party, on their schedule, for a fee. That is the actual barrier, and it is why so much agent-readiness advice reads as homework nobody hands in.

The way around it is to stop asking. Pages and tools can be served at the edge, on your own hostname, on a narrow set of paths, without touching your CMS and without anyone at your website vendor approving anything. Your existing pages behave exactly as they did before, because every other request never reaches the layer at all.

That is a deployment detail rather than a protocol, and it is the difference between a spec you agree with and a thing that is live on Thursday.

What to actually do

Three things, in order.

1. Find out what an assistant can read about you now. Not what your site looks like. What comes back when something that cannot run JavaScript asks for your pages.
2. Fix the read layer, because a tool layer on top of wrong hours is a faster way to be wrong.
3. Then give the agent something to press. Search, availability, price, book. Start with the one question that loses you the most customers and make that one finishable.

The businesses that get this right will not be the ones with the best content. They will be the ones an assistant can actually do something with.