🤖 AI & Agents · 9 min read
Can AI Fill Out a Form for You?
Yes, for text boxes and dropdowns, if the page publishes the form as a tool. Two HTML attributes do the publishing: toolname and tooldescription. File uploads do not work, and that is measurable rather than a marketing caveat. That answer covers the question people type as “can ai fill out a form for me” or “can ai fill out online forms”. The rest of this page is the two attributes, a field-by-field breakdown, and what we read back from five of our own pages in a browser with the feature switched on.
What can an AI assistant do with a form today?
A form on a web page is a set of labelled fields plus a submit action. Everything an assistant needs is already there in the markup, but the markup was written for a human eye, and nothing in it announces that a machine may fill it in. WebMCP is the proposal that adds that announcement. It comes in two shapes, and the overview page lists the second one first because it is the common case: “Fill in structured forms: Build a submit_applicationtool to help agents map data collected from the conversation with the user to form fields correctly.”
| Route | What you write | When it fits |
|---|---|---|
| Declarative | Attributes on your existing form element | An ordinary contact, booking or enquiry form |
| Imperative | JavaScript that calls registerTool | An action that is not a form, or one that needs typed input |
The declarative route is worth ten minutes of anyone's time, because it needs no JavaScript and no new endpoint. What the browser does with it is described plainly in the declarative API documentation: when an agent calls the tool, the browser brings the form into focus and fills its fields, and the form stays visible to the person watching.
What does the page have to add?
Two attributes on the form. toolname names the tool after the action it performs, and tooldescriptionsays what invoking it does. Removing either one unregisters the tool, so they travel as a pair. The documentation's own example puts a support form on the web:
<form toolname="supportRequestTool"
tooldescription="Submit a request for support."
action="/submit">
<label for="firstName">First Name</label>
<input type="text" name="firstName">
<label for="lastName">Last Name</label>
<input type="text" name="lastName">
<select name="select" required
toolparamdescription="Determines what team this request is routed to.">
<option value="Customer happiness team">Return my purchase.</option>
<option value="Distribution team">Check where my package is.</option>
</select>
</form>Field descriptions are the optional half, and they are where the fallbacks live. Add toolparamdescriptionand the browser uses your sentence as the parameter description. Leave it out and the browser reads the content of the field's associated <label>, skipping any labelable descendants. With no label at all it looks at aria-description. An element carrying requiredlands in the schema's required array, which is why the select above shows up as mandatory.
None of this is a separate page or a second form. It is the same form, annotated, and a browser that has never heard of WebMCP ignores the attributes and renders exactly what it rendered before.
What we measured on five of our own pages
Claims about agent-readiness are easy to make and easy to get wrong, so on 19 September 2026 we opened five of our own pages in a Chromium build with the feature enabled, awaited navigator.modelContext.getTools(), and printed the name and parameter list of every tool the page offered an agent.
| Page | Tool from the form | Parameters it got | Tool registered in code | Parameters it got |
|---|---|---|---|---|
| /tools/csv-splitter | splitLargeCsv | none | splitCsvText | csvText, rowsPerFile |
| /tools/csv-delimiter-converter | fixCsvDelimiter | none | — | — |
| /tools/json-csv-converter | convertJsonCsv | textInput | convertJsonCsvText | text, direction |
| /tools/csv-analyzer | (none declared) | — | — | — |
| /agent-ready | (none declared) | — | — | — |
Read the first two rows together and the pattern is obvious. The forms that produced zero parameters are the ones whose only input is a file picker, and one of them even carries toolparamdescription on that input plus a matching label. Neither detail saved it. The assistant could see a tool called splitLargeCsv, could explain what it does, and had nothing to hand it: no file property, no bytes, no URL. Software that can be found but not used is worse than software that is not there, because it wastes a turn.
The third row shows the other half of the lesson. That form has a <textarea name="textInput"> and a file input, and only the textarea reached the agent. The same page also holds two <select> elements and a checkbox with labels that are not bound to them and no name attribute on any of them. Those three fields never appeared in the parameter list either. From one page we cannot say whether the missing piece was the name or the loose label, so the safe habit is to give every field both a name and a toolparamdescription and check the result.
The registered tools behave as their schemas promise, which we checked the same afternoon by calling them. Passing five data rows and a rows-per-file value of two into splitCsvText returned three files, each repeating the header row, and the contents matched what we computed independently in Python. A conversion tool turned two JSON records into a two-column CSV and flattened a nested object into meta.score. An empty csvText argument came back refused with “csvText is empty — pass the CSV content to split”, which is the reason to trust the other two results: the tool is really running, not reciting a canned reply.
Which field types reach the agent, and which do not?
The documentation covers the common elements; our measurements fill in the edges. What we can support with evidence is below, and anything outside it is marked as untested rather than guessed.
| Field | Becomes a parameter | Evidence |
|---|---|---|
| Text input | Yes | In the documentation's example form |
| Textarea | Yes | Named textarea surfaced as textInput on our converter page |
Select with name and required | Yes | Shown in the documentation example, options becoming the value set |
| File input | No | Two forms, one with an explicit parameter description, both reported none |
Select or checkbox with no name | No, observed | Three fields on our converter page never appeared |
| Number, date, checkbox with a name | Untested | Not present in our pages, and not spelled out in the docs we read |
One more limit is worth naming, because it decides how much of your workflow can move. A declaration describes a form that exists in the page at the moment the browser looks. A multi-step wizard whose second step is created after a click, or a form hidden behind a sign-in, is a different problem, and the imperative API is the tool for it: you register a named tool with a typed schema and handle the state yourself.
Can AI fill out a PDF or a Google Form?
Not through this API, and the reason is structural rather than temporary. The attributes work on a formelement in a document you control, where the browser can read the fields and write into them. A PDF is a file, and a form inside somebody else's product belongs to that product. For those surfaces you need that vendor's own automation, a file-level tool that parses the document, or a copy of the questions on a page of your own where you can annotate them.
Does the person still have to press Submit?
You decide, and there are exactly two documented options. The first is the familiar one: the assistant fills the fields and the user clicks Submit. The second adds the toolautosubmit attribute, and the browser submits and navigates when the model invokes the tool. The SubmitEvent interface carries an agentInvoked boolean so a single handler can branch on which path fired, which is the cleanest place to add a confirmation step or a different log line.
Start without automatic submission. A form that submits itself on an assistant's say-so is a form that will eventually submit something you did not want, and the human click costs a second.
How do you check whether your own form is ready?
- Search the source for
toolname. If it is absent, nothing else on this list matters yet. Turn WebMCP on for the page and add the two attributes. - Confirm the attributes sit on the form, not on a wrapper. The declaration belongs to the
<form>element itself. - Read the parameter list back. In an enabled browser, await
getTools()and inspect your tool. No parameters at all is the signature of a file-only form. - Cover the file path separately. If a file is genuinely required, add a text route or a registered tool that accepts content, the way we did for splitting a large CSV.
- Keep your server checks. Validation, rate limits and spam filtering are unchanged by any of this.
A form is the cheapest agent-facing interface a small site has. You already built the fields and the handler; the declaration is two attributes, and the one failure mode worth watching for is a tool that shows up with nothing to give it.
Frequently asked questions
Can AI fill out a form for me?
Yes, if the page publishes the form as a tool. Two HTML attributes on the form element, toolname and tooldescription, register it with the browser's WebMCP layer, and an assistant running in that browser can then see the form, fill its text boxes, text areas and dropdowns, and read the values back. A form with neither attribute is invisible to the assistant, no matter how ordinary it looks to you.
Which attributes make a form usable by an AI assistant?
toolname and tooldescription go on the form element and both are required; removing either one unregisters the tool. Optionally, toolparamdescription goes on individual fields to describe each parameter. Without toolparamdescription the browser falls back to the content of the field's associated label, and if there is no label it uses aria-description. An element marked required is listed in the parameter schema's required array.
Can AI attach a file to a form?
Not today. In our own measurement, three forms whose only input was a file picker registered as tools with an empty parameter list: the assistant could see the tool by name and had nothing to pass into it. That held even when the file input carried an explicit toolparamdescription and an associated label. If a workflow depends on a file, the page needs a text path or a hand-registered tool with a typed schema.
Can AI fill out a Google Form or a PDF form?
Not through this API. The declarative attributes work on a form element inside a document you control, where the browser can read the fields and write into them. A PDF is a document rather than a page, and a form inside somebody else's product belongs to that product. Those surfaces need the vendor's own automation, a file-level tool, or a copy of the form on a page of your own.
Does the assistant submit the form, or does the user?
You choose. Chrome documents two modes: the user clicks Submit as usual, or you add the toolautosubmit attribute and the browser submits and navigates when the model invokes the tool. The SubmitEvent interface carries an agentInvoked boolean, so one handler can tell which path fired. Starting without automatic submission keeps a human in the loop.
Do I need JavaScript to make my form agent-ready?
No for the declarative path. Adding the attributes to server-rendered HTML is enough, and browsers that do not implement WebMCP ignore them, so the form keeps working as before. JavaScript is only needed for the imperative path, where you call navigator.modelContext.registerTool yourself to publish a tool that is not a form.
Will declaring my form as a tool break it for human visitors?
It should not. The attributes are metadata, and they do not change rendering or validation. What they do change is that a new kind of visitor can reach your endpoint, so keep the server-side checks you already have: validation, rate limits, and spam filtering all still apply to whatever the assistant sends.
How do I check whether my own form is ready?
Search your page source for toolname. If it is missing, nothing else matters. If it is there, open the page in a Chromium build with WebMCP enabled and call navigator.modelContext.getTools(), then look at the parameter list of your tool. A tool that reports no parameters is the signature of a form whose only input is a file, or of fields that were never given a name.
Tools mentioned in this guide
The attributes take a text editor. These are for the parts around them, where a form meets real traffic:
- OpenCode Go — writing the tool declaration is a five-minute job, but checking that every field ends up as a parameter is the sort of loop a small script does faster than a person clicking through the form each time. Try OpenCode Go
- Stack AI — if a submitted form should route somewhere (a CRM row, a summary email, a spreadsheet), a workflow saves writing that plumbing by hand. Try Stack AI
- Softr — for directory and catalogue sites, a published collection gives you pages with stable URLs, which is what an agent needs before it can point a form submission at the right record. Try Softr
Some links above are affiliate links — if you buy through them we may earn a commission at no extra cost to you. OpenCode Go uses our referral link; the other two currently point to each vendor's official page until our tracking links are approved.
Want the Declaration Checked on Your Own Form?
The measurements on this page come from live pages, not from a demo. If you would rather have someone turn your form into a working tool and verify the parameter list, that is the work I do.
I build this layer for other sites: llms.txt, agent-tools.json and WebMCP declarations, verified against the live pages. Details at /agent-ready.
Related reading
AI & Analysis — other guides that pair well with this one.
Browse all guides in the NoCodeCSV blog.