The declarative WebMCP API does something that sounds too small to matter: it turns an HTML form you already have into a tool an AI agent can call, by adding two attributes to the <form> tag. No JavaScript, no separate server. This is the cheapest piece of genuine agent-actionability you can ship, the point where your site stops being something an agent merely reads and becomes something it can operate. It is also experimental, gated behind a Chrome flag and an origin trial, and it will not move your Agentic Browsing audit score today. Build it as positioning and future-proofing, and know exactly what the two attributes do before you add them.
The whole declarative API is two attributes
Both attributes go on the <form> element itself, not a wrapping <div>, not the submit button. toolname names the tool; tooldescription says what it does. Miss either one and the browser does not register the form as a tool at all. Every input that should become a parameter needs a name attribute; inputs without one are silently dropped. The browser reads the form and generates a structured JSON tool schema from it, you write none of that schema by hand.
<form toolname="request_solar_quote"
tooldescription="Request a solar installation quote. Collects property type, roof type and contact details.">
<input type="text" name="full_name">
<input type="email" name="email">
<select name="property_type" toolparamdescription="Type of property the quote is for.">
<option>Detached house</option>
<option>Commercial</option>
</select>
<button type="submit">Get my quote</button>
</form>One honesty note before you build on this: the declarative half of WebMCP is the less settled part of the spec, described by Chrome’s own team as an evolving direction rather than a finalised contract. The attribute names above are current as of writing; the durable advice in the rest of this guide will outlast them even if the syntax shifts.
Name the tool like the action it performs
Agents choose which tool to call from the name and description, so these are the new meta descriptions, conversion copy for a machine. Make toolname a clear verb-led action: request_solar_quote, book_appointment, search_catalogue, not form1. Make tooldescription specific about both the action and the inputs: “Search the catalogue by keyword, category and price” beats “Search”. Where a field is ambiguous, add toolparamdescription to it so the agent maps it correctly. And if your form uses custom UI, styled radio cards or a button group instead of a native <select>, add a hidden native <select> alongside it, because agents can only discover options through standard form elements.
Keep the human in the loop
By default, when an agent calls the tool the browser brings the form into focus, fills the fields visibly, and waits for the person to review and submit. That visible, human-confirmed execution is the entire safety model, and a trust feature, because the user watches the task happen rather than handing control to a black box. There is an optional toolautosubmit attribute that lets the agent submit without a click. Use it only for read-only or genuinely low-risk actions like search or lookup. For anything that creates a lead, a booking or a payment, leave it off. A quote request is a write action; the human confirms it.
The WordPress wrinkle: your form is probably not in your theme
This is where most WordPress implementations go wrong. If your form is rendered by a plugin, Formidable, Gravity Forms, Contact Form 7, the <form> tag is generated at runtime by the plugin, not sitting in a template file you can edit. Editing a page template will never catch it, and hand-editing the rendered markup breaks the moment someone re-saves the form in the plugin’s builder. The right move is to add the attributes through the plugin’s own form-HTML filter, so the annotation is applied every time the form renders and survives every future edit.
For Formidable, the durable approach is to filter the final rendered form HTML and inject the attributes into the opening <form tag:
add_filter( "frm_filter_final_form", function( $html ) {
// Target only the relevant form (check its id) before injecting.
return preg_replace(
"/<form /",
"<form toolname="request_solar_quote" tooldescription="Request a solar installation quote." ",
$html,
1
);
} );Confirm the exact hook name against your installed Formidable version before relying on it. If a server-side filter is awkward, a small enqueued script that adds the attributes to the form by its container id on load is a workable fallback, it also survives form edits, though declarative-via-JavaScript is slightly less clean and the timing of registration can affect whether an audit snapshot catches it.
Test it before you trust it
The API is an early preview: you need a recent Chrome (the early preview landed in Chrome 146; the origin trial was confirmed for Chrome 149), with the WebMCP testing flag enabled at chrome://flags/#enable-webmcp-testing. Then, in DevTools, list the registered tools to confirm yours appears, and execute it with test input to dry-run the submit path. If your tool does not show up, work the checklist: are both toolname and tooldescription present and on the <form> itself? Is the form actually in the DOM (not hidden behind a conditional)? Does every input have a name?
Hold the imperative API for now
There is a richer, JavaScript-based path, navigator.modelContext.registerTool(), for exposing actions that are not forms, with a hand-written schema and an execute callback. It is genuinely interesting, and a strong thought-leadership angle, but it is more experimental and more involved, and not something to rush onto a live client site. One trap if you ever run both: a declarative tool and an imperative tool must have different names, or Chrome throws a duplicate-name error. Start declarative, on your highest-intent form, and learn from that.
What this is worth today
Be clear-eyed. This is experimental, it requires a bleeding-edge browser with a flag set, and it will not raise your Agentic Browsing audit score right now, that category is informational and the WebMCP checks need the origin trial. So why do it? Because it is two attributes; because the durable principles, name tools as actions, keep the human in the loop, annotate through a filter not a template, will outlast any change to the syntax; and because it is the on-site move that matches where this is heading. Once an agent is already on your site and ready to act, a callable tool is the fit, not a file that declares what you sell. This is the fourth floor of the Four-Floor Model, agent execution, made real on the one form that matters most to your business. The concept and the commercial case sit in the WebMCP guide; you can see our own agent-readiness verified on the proof page.
Currency note: the declarative attribute syntax is experimental and the specification is moving. Verify the attributes and the Chrome version against Chrome’s WebMCP documentation before you publish this or ship it to a client. The judgement in this guide, which form to expose, how to name it, when to allow auto-submit, how to annotate a plugin-rendered form, holds even if the exact attributes change.
