browser_fill_form

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It adds useful performance context ('faster', 'reduces turn count') and the fact that multiple elements are filled at once, but it does not disclose whether the form is submitted, whether input/change events are dispatched, whether it waits for actionability, or what happens on element-not-found errors. For a browser mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero waste, front-loaded with the core purpose. The preference and rationale follow in logical order, and every sentence contributes either scope, routing guidance, or justification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich input schema and no output schema, the description covers purpose and when-to-use adequately. Its main omissions are behavioral: whether filling submits the form, how errors are surfaced, and whether events are triggered. These are meaningful for a browser automation tool but less critical than the schema's element-level documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by enumerating the supported element types (inputs, selects, checkboxes, radios), which the schema itself does not list. It does not explain the array structure or the required 'text' field, but the schema handles those details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Fill out multiple form elements (inputs, selects, checkboxes, radios) at once.' It also implicitly contrasts with the single-element siblings by naming the individual 'fill' or 'click' calls. An agent can immediately tell what this tool does and how it differs from browser_fill and browser_click.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to prefer this tool over multiple individual 'fill' or 'click' calls when interacting with forms. The condition ('when interacting with forms') and the rationale ('significantly faster and reduces turn count') are both given, leaving little to inference. The only missing nuance is a negative case for single-element forms, but the preference statement implies it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.