We made four websites agent-ready with WebMCP

WebMCP lets a website hand AI agents typed, safe tools instead of leaving them to scrape. We shipped it across four production sites in a day: read-only tools, human-confirmed forms, and a machine-readable content index that any agent can use.

AI agents are visiting your websites, not just people#

Some of the traffic hitting your website right now is not human. It is an assistant summarising you for someone who asked a question, a shopping agent checking whether you sell what they need, or a browser-based agent trying to fill in your contact form on a customer's behalf.

Websites are built for eyes. Agents do not have eyes. They pull down your HTML, burn tokens working out which div is the navigation and which button submits, and then guess. Sometimes they guess well. Sometimes they confidently tell a potential customer something about your business that is wrong, and you never find out.

We had already done the obvious first move across our sites: llms.txt, a plain-text file that describes your site for language models. It helps, but it is a static description, not an interface. WebMCP has real engineering behind the structured-tools approach, and it gave us a practical next step.

So on Saturday we made all four of our websites agent-ready: cloverbase.com, nz365guy.com, megsmith.nz, and hitechhippies.co.nz.

What WebMCP actually is#

WebMCP is a proposed web standard developed in the W3C Web Machine Learning Community Group, with contributors from Google, Microsoft, and the wider web community. The Chrome origin trial began with Chrome 149.

The idea is simple to say: instead of an agent interpreting your page, your page registers tools. A tool is a named function with a description, a typed input schema, and a defined result. An agent visiting the page can list the tools, understand what each one does, and call them directly.

If you know the Model Context Protocol (MCP), the mental model is close. MCP standardised tools between AI applications and backend services. The WebMCP explainer describes a web-native version of that idea in the browser. Your page exposes tools using its existing interface, state, and permissions.

The Chrome WebMCP documentation describes two halves. An imperative JavaScript application programming interface (API) lets a page register tools. A declarative API works with HTML forms, allowing the browser to derive a tool from the form and its annotations.

What we shipped#

Every one of the four sites now registers three read-only tools: one that returns an overview of the site and its key pages, one that lists published posts by category, and one that searches the full archive by keyword.

They are backed by a machine-readable index of every published post, refreshed hourly. Any agent can fetch that index directly, whether it speaks WebMCP or not. Our llms.txt files now point straight at it.

The forms came next. Email signup on all four sites, contact forms on two of them, and the ask-a-question form on Cloverbase are annotated as declarative tools. An agent can find them, understand them, and fill them in.

What an agent cannot do is submit them.

The safety stance: agents read, humans act#

We deliberately shipped zero write tools. Every action on our sites still ends with a human reviewing a filled-in form, passing the same verification as any other visitor, and clicking the button themselves.

This is a design position, not a temporary omission. The agentic web is going to have a trust problem, because an agent that can read your calendar and spend your money is only as safe as the worst site it visits. The sites that win in that world will keep people in control by construction and be able to prove it.

Read everything. Act on nothing without a person. That is our default until the standards and the agents earn more.

Three things the build taught us#

The ground moves while you are standing on it#

Almost every tutorial and polyfill we found targeted an API entry point that changed while the proposal evolved. If we had installed a third-party wrapper, we would already be carrying stale calls.

Instead, we wrote our own thin compatibility layer, about 60 lines, that detects both entry points. When you adopt a draft standard, own the thin layer yourself. It is the part most likely to change.

Agents inherit your data quality#

Our first version of the content index reported that this site had 36 posts. It actually serves 327. Everything older than two years carries an archived banner, and our first query excluded it.

An agent reading that index would have told someone I barely write. One flag fixed it, and now the index covers the full archive with older posts clearly marked.

Audit what your machine-readable surfaces claim about you, because agents will repeat it with total confidence.

Ship dormant, activate with a header#

The code went to production doing nothing. Activation uses a per-site token from Chrome's origin trial console, delivered in a response header and switchable off in one step.

The rollout was reversible at every stage, added zero dependencies, and cost about a day across four production sites. If WebMCP does not progress beyond the trial, we still keep a content index and annotated forms that make the sites easier for agents to understand. The downside case is fine.

Why do this now#

Origin trials exist so ordinary sites can learn cheaply while a standard is still being shaped. By the time something like WebMCP ships broadly, agent-readiness may be table stakes, and the learning will be expensive and rushed. Right now it is a weekend project.

You do not need a platform team for this. We are a two-person business in Northland, and we put it on four production sites in a day.

The interesting question is no longer whether agents will visit your website. They already do. The question is whether they get the truth, and whether they can act safely, when they arrive.

Try it yourself#

To inspect WebMCP locally, install a current Chrome release, enable the WebMCP testing flag at chrome://flags/#enable-webmcp-testing, install the Model Context Tool Inspector extension from the Chrome Web Store, and visit any of our four sites. You can see the registered tools and call them with test inputs.

If you want to build it, start with the Chrome WebMCP documentation and register your origin for the trial. Keep your first tools read-only, keep people on the submit button, and keep your own thin layer over the API.

Our current origin-trial tokens run to 17 November 2026. Between now and then, we will watch what agents call and write up what we find.

What to do next#

1. Publish a complete llms.txt file and a machine-readable content index.
2. Expose one useful read-only WebMCP tool behind a thin compatibility layer.
3. Test tool discovery and calls with Chrome's inspector extension.
4. Keep every write or submission behind explicit human review.
5. Audit the answers agents receive against the content people can see.

---

Mark Smith is Principal AI Strategist at Cloverbase. To discuss this article or work with me, contact me at Cloverbase.