A few weeks ago I watched a customer try to book a job without ever opening my client’s website. They asked their assistant — the chat one, on their phone — to “find a local guy to regrout a shower and get me on the schedule this week.” The assistant found three businesses. It read all three sites. Then it came back with a summary and a flat recommendation: “Here are their phone numbers.”
That was the whole transaction. The agent did the finding. It could not do the booking. So it handed a phone number back to a human who, two-thirds of the time, never calls.
I have spent years getting small-business sites found — schema markup, fast pages, the local SEO grind, and lately the new discovery layer everyone’s scrambling at: llms.txt, clean structured data, getting quoted inside an AI Overview. All of it still matters. But that booking moment made the next problem obvious. Being found is table stakes now. The businesses that win the next few years are the ones whose websites can be operated by an agent, not just read by one.
Two different jobs, and most sites only do the first
There are two separate things an AI agent needs from your website, and they are not the same skill.
Discovery is “can the agent understand what you are?” That’s content. Schema.org markup, a clean llms.txt, descriptive headings, an honest services page. This is the SEO conversation, extended to machine readers. We’re all reasonably good at it now.
Interaction is “can the agent do the thing?” Check real availability. Build a quote from the actual price list. Start a contact request that lands in your CRM. Add the item to a cart and hold it. This is not content — it’s capability. And almost no small-business site exposes any of it to an agent.
Here’s the analogy I keep using with clients. Discovery is putting your menu in the window so people walking by can read it. Interaction is having a waiter who can actually take the order. A read-only site is a menu in a locked window. The agent presses its face to the glass, reads everything, and then tells its human to go find a door.
What actually breaks when the site is read-only
When an agent can only read, every action degrades into a handoff to a human:
- It can’t see that your Thursday is already full, so it suggests Thursday.
- It can’t price the job, so it guesses from a “starting at” number and sets the wrong expectation.
- It can’t submit the contact form — those are built for human eyes and mouse clicks, often behind a CAPTCHA — so it copies your phone number into the chat and wishes the user luck.
- It can’t hold the last in-stock item while the person decides.
Every one of those is a dropped transaction. And it’s dropped silently — you never see the lead, because the lead never became a click. Your analytics show nothing. You just quietly stop being the business the agent can complete a job with, while the competitor whose site can close the loop becomes the default recommendation.
WebMCP: a site that hands the agent a set of buttons
The piece that’s been missing is a standard way for a website to say, in the browser, “here are the things you’re allowed to do here, and here’s how to call them.” That’s what WebMCP is.
If you’ve heard of MCP — the Model Context Protocol that lets AI tools plug into external systems — WebMCP is the in-the-page version of the same idea. A site registers a small set of tools on the browser API navigator.modelContext: named actions, each with a description and typed inputs. When an agent lands on the page, it can read that menu of tools and call them — the same way a person reads your buttons and clicks them.
The important part: these aren’t a parallel universe. The tools wrap the exact same operations your real UI already uses. The “request a quote” tool calls the same endpoint your quote form posts to. The “check availability” tool reads the same calendar your booking widget reads. You are not building a second website for robots — you’re putting a second set of handles on the one you already have.
What we actually built
I don’t like writing about things that don’t exist yet, so here’s the real version running on our own properties and shipping into client sites.
We built a small library — internally it’s @org/webmcp — plus a polyfill so it works in browsers that don’t yet ship navigator.modelContext natively. On a site, it registers a handful of tools that map to what that business actually does:
search_services— return the real service catalog, with real prices, not a scraped guess.check_availability— read live open slots so the agent never proposes a full day.request_quote/start_contact— open a structured request that lands directly in the CRM as a lead, attributed and ready to follow up — no form-spoofing, no CAPTCHA wall.- For the storefront sites,
add_to_cartandget_order_status— so an agent can assemble an order and a human can confirm the checkout.
Then, at the front door, we publish machine-readable descriptors under /.well-known/ — the agent’s equivalent of a site map for capabilities instead of pages. An agent (or a remote MCP client) can hit one URL and learn what your business can do before it even renders the page. Discovery and interaction, advertised together.
Crucially, the human site is untouched. Same pages, same widgets, same speed. The agent layer rides alongside it. If an agent never shows up, nothing changes. If one does, it finds a waiter instead of a locked window.
”Isn’t this a security hole?”
Good instinct, and the answer is only if you build it lazily. The tools you expose are a deliberate, small list — the same things you’d happily let a customer do on the public site, never the admin operations. Writes still go through the same validation, the same rate limits, the same auth your real endpoints already enforce. An agent calling request_quote is doing exactly what the form does; it just doesn’t need a mouse. You are widening the door, not removing the locks. We treat the agent like any other untrusted client, because it is one.
Why I think this matters more for the small guy than the enterprise
Big companies will get agent-interactive eventually — they have teams for it. The interesting leverage is at the bottom of the market, where it’s currently a level playing field of locked windows. Right now, none of the three regrout guys can take the agent’s booking. The first one who can becomes the one the assistant recommends and completes — not because they ranked first, but because they were the only one the agent could finish the job with. That’s a durable advantage you can grab today, before it’s table stakes, for roughly the cost of wiring up a few tools onto endpoints your site already has.
The discovery race — being found by AI — is already crowded. The interaction race has barely started. Get found, yes. Then give the agent something to do when it gets there.
If your site can be read by an agent but not operated by one, that’s the gap we close. It’s a small, concrete piece of work on top of what you already have — and it’s the difference between an agent reading your phone number aloud and an agent putting a job on your calendar.