How one site added WebMCP tools for AI agents, in working code

A team that builds WebMCP integrations for clients has published a step-by-step account of adding the technology to its own website, complete with the code it shipped. The post on dev.to, by UnlockLive, documents three tools registered on a live service page and a set of practical cautions for anyone considering the same move.

What WebMCP changes

Most AI agents today use websites the way a person with no instructions would: they load the page, work out which control probably does what, and click. A popup, redesign or layout change can defeat the whole approach. WebMCP, a proposed web standard, offers a different contract. The page registers named tools with descriptions and input schemas, and the agent calls those tools directly rather than inferring intent from the interface.

According to the post, the standard is very early: as of October 2026 it ships in Chrome behind a flag and as an origin trial, and neither Firefox nor Safari has announced support.

Three tools, read-only first

The team kept the surface deliberately small. get_webmcp_services returns the company's packages and contact details. answer_webmcp_question searches the FAQ already on the page and returns up to three matching entries. prepare_audit_request fills in an audit form for the visitor but transmits nothing — the person reviews the filled form and presses submit.

Two of the three are read-only, which the authors recommend as the starting point: lookup tools carry the least risk and most of the immediate value.

The patterns in the code

The support check reflects churn in the API itself. During 2026 the entry point moved from navigator.modelContext to document.modelContext, so the code reads whichever exists and exits quietly if registerTool is not a function. Pages in browsers without WebMCP simply skip everything.

Registration is one call to registerTool() with a name, a description written for the agent rather than for humans, an input schema, annotations such as readOnlyHint: true, and an execute function. The FAQ search is deliberately unambitious: it tokenizes the incoming question, scores each FAQ entry by keyword overlap and returns the top three results as JSON. The authors point out that the tool just repackages data the page already holds, which keeps it correct by construction.

The one tool that touches state, the audit form, is guarded carefully. Its execute function dispatches a custom uwm:prefill event carrying trimmed field values, scrolls the form into view, and returns a string telling the agent that the visitor will do the submitting. The authors' rule: anything that sends a message, books something or changes a cart needs the visitor's approval, and the server keeps enforcing permissions exactly as before.

A shortcut without JavaScript

The post also shows a declarative route. Adding toolname and tooldescription attributes to an ordinary HTML form element turns that form into a tool; the browser fills in the fields and shows them, and by default the visitor still presses the button.

What the authors would tell you first

The caveats are as concrete as the code. There is no evidence WebMCP affects search rankings, so it should not be pitched as a traffic play. It is also not a substitute for a remote MCP server: WebMCP runs in the page, inside the visitor's session, while an MCP server runs on your infrastructure for AI applications. The authors advise treating the work as preparation, since few agents use it today and the API may still change. Above all, never expose administrative functions or another customer's data through a tool.

One commercial note: the authors sell WebMCP integration services and offer a free checker that scans pages for registered tools. The technical advice stands on its own, but the enthusiasm has a business behind it.

Why it matters

If agent-driven browsing becomes common, sites that expose typed, documented tools give automated clients a reliable alternative to vision-based guessing — and regain a measure of control over what agents can and cannot do. This post shows the cost of experimenting is low: a few lines of JavaScript or two HTML attributes, read-only by default, and silent degradation on unsupported browsers. For agent developers, it sketches the other side of the contract: schemas and descriptions they can call instead of reverse-engineering the DOM. The open question is whether a standard that today exists mainly as one browser's origin trial will stabilise, and spread, widely enough for either side to build on it.