WebMCP: Will AI Agents Use Your Website, or Only Read It?
The short answer
An AI agent can read a website; using one is different. WebMCP is a browser draft that lets a page describe its forms and tools to an assistant in the visitor's browser. Describe yours now: it costs one attribute per field and two on the form, browsers without it ignore them, and by default the button stays with the person.
Almost everything done to this site in the past year has been about being read. Prerendered pages, questions as headings, an answer in the first two sentences, a plain-text copy for assistants: the post on getting cited by AI walks through it. Reading is where the work stopped, because reading was all an assistant could do.
That is changing. A person can now ask an assistant in their browser to request the quote, book the table or send the enquiry, and the assistant has to work out how. On an ordinary website it guesses: it finds a form, reads the labels, and fills the boxes the way it thinks you meant. WebMCP is the proposal that lets the page tell it instead.
What is WebMCP, in plain words?
WebMCP is a draft browser feature that lets a web page describe its own tools to an AI agent. The draft is written by a W3C community group with editors from Microsoft and Google, and the specification marks itself a community group draft rather than a standard, read 29 September 2026.
A form gets two extra attributes, a tool name and a sentence saying what the form does, and each field gets one: a sentence saying what goes in it. Anything else, a calculator or a search box, registers a function with a name, a description and a list of inputs.
One rule in the draft matters more than the rest for a small business. Unless a form carries a further attribute called toolautosubmit, the agent fills it in and the browser puts the submit button in focus. The agent then asks the person to check the form and press the button themselves (the declarative explainer, read 29 September 2026).
Where it runs today is narrow. Chromium's own feature list marks WebMCP as experimental (runtime_enabled_features.json5). A site joins the trial by serving a token, and one project that serves a token records its expiry as 17 November 2026 (assistant-ui issue 7652), which is the date this post gets re-read.
What is the difference between an agent reading your site and using it?
Reading is what search engines and assistants have always done: fetch the page, pull out the facts, quote or cite them. Using the site is the next step: the assistant fills the plumber's quote request with the caller's suburb and the fault, on the caller's say-so, and gets it to the point where the caller presses the button.
On an undescribed form the agent works from what it can see: the label beside a box, a placeholder, the order of the fields. That is a guess, and the failures are specific: a suburb in the street field, a business name where the person's name goes, a consent box ticked because the agent thought that was helpful. On a described form each field carries a sentence the business wrote, saying what belongs there and when to leave it blank. A guessed form produces an enquiry someone has to ring about twice. A described form produces the enquiry the customer meant to send.
Which tools should an agent be allowed to submit on its own?
The WebMCP draft's default for a form is the right one: no autosubmit unless the page opts in. That leaves a decision per form, and the useful distinction is between a query and a consequence.
A query changes nothing. Opening hours, whether a size is in stock, what a job might cost from four numbers, the next free slot on a calendar. An agent can run those on its own and read the answer back. This is where AI customer support tools belong: a read-only tool that answers the question a person would otherwise ring about.
A consequence sends a message, spends money or changes an account: a booking, an enquiry, a purchase. Those are filled by the agent and sent by the person, which is what the draft tells the agent to do. Our rule is simpler than any list: if a human would want to see it before it went, the human presses the button.
What did we describe on durbacti.com, and what did we keep hidden?
Durbacti describes two tools on durbacti.com, shipped on 27 September 2026: the form's attributes in the page's HTML, the calculator's tool in its script.
The enquiry form is a tool called submit_enquiry. Nine fields, each with a description of a sentence or two: the work email address Durbacti replies to, which of six services fits best, what the person wants to automate in their own words, a consent box the description says never to tick unasked. The form's own description tells the agent to fill it from what the person said and invent nothing, and that nothing is sent until the person presses the button. There is no autosubmit. If a submit reaches the page through the tool, it answers in plain words: sent, do not send again; not sent, do not retry; or which field to fix.
The missed call calculator is a tool called estimate_missed_call_cost. It takes four numbers, returns the figures and the working line by line, and says what the result is: the most that unanswered calls could be costing, not a quote and not a forecast. It runs in the visitor's browser, Durbacti receives nothing from it, and an agent may run it freely.
What we kept hidden is as deliberate. The form carries a spam trap, a hidden field a human never fills and a crude bot tends to. That field has no name, so the schema the draft builds from a form has no slot for it. And the build refuses to deploy if a field loses its description, the trap regains a name, or the tool name changes, so the form an agent sees and the function behind it cannot drift apart.
An enquiry sent by an agent lands in the same table as one taken by our 24/7 AI phone receptionist, which keeps the same rule on the phone: never act without the person.
Where this stands today, said plainly: the two tools are in the pages, and the trial token that lets a visitor's Chrome expose them is the next step. The day it is live, a dated line will be added here.
Why will describing your forms become the default even if WebMCP never ships?
Describing your forms will become the default because the cost is one attribute per field and the failure mode is nothing. A browser that does not know the attribute ignores it, as HTML has always treated unknown attributes, so the page looks and works the same everywhere. If the trial ends, the site has lost a few hundred bytes of text.
The counter-evidence deserves the same weight. The makers of Safari have recorded a position of opposition, naming privacy, security, duplication and API design among their concerns (WebKit standards positions, issue 670). For Firefox, the draft's status page lists only an issue in Mozilla's standards-positions tracker (issue 1412) and a Bugzilla entry, nothing shipped. A W3C Technical Architecture Group review has been requested (design review 1238). Google's own explainer of origin trials says: "There is a good chance that some of them will never ship as standardized APIs on the web" (the origin trials explainer).
Web Bluetooth shipped in Chrome and Edge and never in Firefox or Safari (caniuse data); FLoC was replaced by the Topics API (the FLoC repository); Portals is no longer pursued (the Portals repository). So the honest position is not that WebMCP wins. It is that describing your forms costs almost nothing either way, and whatever does win will read a described form more easily than a bare one.
Who can use WebMCP tools today?
The draft's own status page (implementation status, read 29 September 2026) lists ChatGPT's desktop application as supporting WebMCP and Brave's Leo chat as experimental. Chrome 149 and Edge 150 expose the tools to an in-browser agent on sites that serve a trial token (Edge's release notes for version 150). For Firefox and Safari it lists no support. We cannot show you a browser agent using our two tools today, and this post does not claim one does.
What does it mean for a quote request or a booking form?
A described form matters differently for a tradie and a clinic, two of the businesses durbacti.com is built for.
A tradie's quote request. The suburb, the fault and the best time to call, described so an agent cannot put the suburb in the wrong box; the person presses send. That is lead generation by agent, with the qualifying fields travelling with the enquiry and the consent box never ticked unasked.
A clinic's booking. A consequence, so the agent fills it and the patient confirms; the read-only tool beside it, the next free slot, is the one that helps most. Smart scheduling is that pair, described.
And the honest limit: WebMCP is a page feature. A native iPhone or Android app has none and an internal web tool does, which is a distinction for a scoping call about app development, not a promise.
What we will not do
Let an agent send anything on its own that sends a message, spends money or changes an account. The person presses the button.
Describe a tool the page cannot do. A description is a promise to a machine.
Offer an agent the spam trap. A field a human cannot see is not a field an agent should fill.
Treat a tool description as trusted text. The draft's security section names prompt injection through tool metadata as a threat (the specification), so every sentence we hand an agent is short, fixed and about the form or the field.
Claim a browser agent uses our tools today when we cannot show it.
What nobody can measure yet
No analytics on this site, by choice, so nothing counts a visit. Search Console has no report for a tool being invoked. In the enquiry table, one filled by an agent and sent by a person looks like one typed by hand: the page knows at the moment of submission and we do not store it, because the enquiry is the same either way.
What to ask any web developer
Does every form carry a tool name, a sentence saying what it does, and a sentence per field?
Which forms submit on their own, and why those and not the others?
What does the agent's view of a form leave out, and is the spam trap on that list?
Does the build fail when a field loses its description?
Does the page behave identically in a browser without the feature, and what happens on the day the trial ends?
If your site is being rebuilt this year, this is one sentence per field and one decision per form, on top of the reading work that gets you cited. Website development in Sydney is where we do it, and a free strategy call is where it starts, whether or not you hire us.
Common questions
Is WebMCP the same as MCP?
No. MCP, the Model Context Protocol, is a protocol for connecting an AI application to tools and data that run somewhere else, over a connection between the application and a server. WebMCP borrows the idea of a tool with a name, a description and a list of inputs, and puts it inside a web page, so the tool runs in the visitor's browser on the page in front of them. A business can offer both, and neither depends on the other.
Does describing a form let an AI agent submit it without me?
Not unless the page says so. A described form without toolautosubmit is filled in by the agent, then the browser puts the submit button in focus and the draft tells the agent to ask the person to check the form and press it. Only a form that carries toolautosubmit is sent through the tool on its own. Durbacti's enquiry form does not carry that attribute, so through the tool nothing is sent until the person presses the button.
Does my site need WebMCP to be cited by ChatGPT?
No. Being cited comes from being readable: prerendered pages, an answer in the first two sentences, questions as headings, honest dates and structured data. WebMCP is about the step after reading, an agent acting on the page for the person. A site with no WebMCP can be cited every day, and a site with WebMCP and nothing readable will not be. Do the reading work first, then describe the forms.
What happens to a WebMCP site in Safari or Firefox?
Nothing changes. The attributes are ordinary HTML attributes, and a browser that does not know them ignores them, the way browsers have always treated attributes they do not recognise. The form works, the page looks the same, and the visitor sees no difference. Safari's makers have recorded opposition to the proposal and the draft's status page lists nothing shipped for Firefox, so a visitor on either browser gets exactly the site they got before.
Can an AI agent be tricked by a website's tool descriptions?
Yes, and the WebMCP draft says so itself. Its security section names prompt injection through tool metadata, inputs and outputs as a threat: a page could write a description that tells an agent to do something the person never asked for. The defence sits on both sides. Browsers and agents have to treat descriptions as untrusted text, and a business describing its own tools should keep every description short, plain and about the field. Durbacti's field descriptions are a sentence or two each, every one about the field.