Forms an agent can fill: what WebMCP changes

An agent asked to submit a form does it the way a person would if they could not read: it takes the rendered page, guesses which box is which from label text, input type and field order, types, and clicks whatever looks like the submit button. It mostly works. It fails on the day somebody rewrites a label, and it fails silently, because nothing in the page ever promised what the third field was for.

WebMCP is Chrome's proposal for removing the guess. The page declares its capabilities as named tools with typed parameters, and the agent calls one instead of interpreting a layout. For a form, the declaration is two HTML attributes on the form and one per field. No JavaScript, and browsers without WebMCP ignore all of it.

What the attributes do

<form id="contact-form"
      toolname="draft_project_inquiry"
      tooldescription="Fill the contact form with a project
        inquiry. Does not send it.">

  <label for="email">Email</label>
  <input id="email" name="email" type="email" required
         autocomplete="email"
         toolparamdescription="Work email to reply to.">
</form>

<!-- Outside the form element, so not parameters. -->
<label><input type="checkbox"> I consent...</label>
<button type="submit" form="contact-form">Send inquiry</button>

The browser derives the schema from the fields: the name attribute becomes the parameter name, required becomes a required parameter, a select becomes an enumeration of its options. Which makes the form element itself a boundary worth choosing deliberately. Everything inside it is something an agent may supply. Anything you do not want supplied belongs outside, which is where our consent boxes, our spam honeypot and our submit button now sit. The button keeps working from there with a form attribute naming the form.

One optional attribute matters more than the rest. With toolautosubmit, the browser submits on the agent's behalf. Without it, the browser fills the fields, brings the form into view, and stops. Filling and sending are separate acts, and the attribute is where you decide which one you are delegating.

Annotating a form makes you audit it

We annotated our contact form, opened DevTools, and Chrome reported two problems immediately. One hidden input had a name but nothing describing it. Another had no name at all. Neither was a field anybody had written that week.

The first was the spam honeypot, which has been there for months: a text input called website, hidden from people, whose only job is to be filled by something that is not a person. The second came from our checkbox component, which renders the visible control as a button and mirrors its state into a hidden input so a form submission carries a value. Both were about to become parameters in a schema handed to agents, one of them nameless, and an agent filling the honeypot would have had a genuine inquiry rejected as spam.

The fix was not to describe them better. It was to move them out of the form element, which is also the honest place for them: neither is a thing a person types. That is worth knowing before you annotate anything. The schema is derived from markup you have not looked at in a while, and the audit is the useful part.

Try it in this article

Six steps: the form as it stands, what an agent has to infer from it, the annotation, the schema the browser derives, the call, and then a live form you can act on. The last step asks your own browser whether it has WebMCP and tells you what it found.

What it does not fix

The schema says what a field is called and what type it holds. It does not say whether the value is true. An agent supplying a project brief on someone's behalf is writing on their behalf, and a well described parameter makes that easier rather than more accountable.

It also does not settle consent. A privacy consent checkbox is a statement by a person about their own data, and a tool call that ticks it has converted a legal act into a parameter. That is a design decision, not a platform bug, and it is the reason to leave toolautosubmit off any form where a box like that appears.

Ordinary autofill is still the larger win

Every browser in use today already fills forms, using the autocomplete attribute, and most forms give it less to work with than they could. A field with no name attribute cannot be filled. A field with a token the browser does not recognise is skipped. An email field that autocapitalises turns a correct address into one that fails validation, and on a phone the wrong inputmode costs the person the @ key.

The same hidden field is a trap in the other direction. A password manager filling by field name will happily write a URL into a field called website, the submission is rejected as a bot, and the person who wrote it gets an error they cannot act on. Hidden fields need the manager-specific ignore attributes, not just to be hidden.

What we changed here

• Per-field autofill tokens and input hints on the contact and newsletter forms, so a one-click fill completes rather than half-completes
• Ignore attributes on both honeypots, so a password manager cannot get a real inquiry rejected
• The name attribute on the project brief field, which had none, so it now posts and fills under a name
• Declarative WebMCP annotations on the contact form, the newsletter signup, and the case update signup
• Consent boxes, honeypots and submit buttons moved outside the annotated form element, so they are not parameters an agent can reach
• No toolautosubmit anywhere, deliberately: an agent may fill our forms and may not send them

The annotation costs an afternoon and expires harmlessly if the standard changes. Delegating the submit costs you the ability to say a person meant it.

What we recommend

Fix the autofill first. It pays off in every browser today, it is the same work either way, and a form whose fields are properly named and described is most of what the WebMCP annotation needs. Then annotate the forms you would be comfortable with an agent filling, and leave autosubmit off until you can answer what happens when the call was wrong.

For anything that carries a consent, a payment, or an irreversible action, the useful question is not whether an agent can reach it. It is which step you want a person present for, and whether your form can still tell the difference afterwards.

Deciding which forms an agent should be allowed to fill, and which stay a person's alone, is a smaller version of a question that gets harder as more of an operation opens up to an agent: which capability, whose permission, what evidence it leaves behind. That is the question an operational AI engagement starts with, on whatever surface is being opened up next.

What is WebMCP?

A proposed web platform API that lets a page declare its capabilities to an AI agent as named tools with typed parameters, instead of leaving the agent to read the rendered DOM and infer. Forms can be annotated declaratively with HTML attributes; other capabilities are registered in JavaScript.

Do the WebMCP attributes break browsers that do not support it?

No. They are unknown HTML attributes, which every browser ignores. A form annotated for WebMCP is an ordinary form everywhere else, and nothing about its submission changes.

Should an agent be allowed to submit a form?

Filling and submitting are separate decisions, and the toolautosubmit attribute is where you make the second one. Leave it off wherever the form captures consent, takes a payment, or does something you cannot undo, so the last action stays with the person at the keyboard.

Is this a replacement for the autocomplete attribute?

No, and autocomplete matters more today because every browser honours it. The two overlap in what they need from your markup: named fields, correct types, and honest descriptions. Doing the autofill work properly is most of the preparation for the agent work.

1. WebMCP overview — Chrome for Developers
2. WebMCP declarative API — Chrome for Developers
3. WebMCP use cases, including form filling — Chrome for Developers
4. Autofill: the autocomplete attribute — HTML Standard, WHATWG