browser_fill

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

No annotations exist, so the description carries the full burden. It does disclose one real behavioral trait — the field is cleared before typing — which is genuinely useful. But it says nothing about what happens when the selector matches nothing, whether the tool waits for the element, or whether Enter submission is possible; these gaps are significant for an interactive browser mutation with zero annotation coverage.

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?

Two short sentences with the action front-loaded and zero filler. It could be slightly better structured by separating the supported element types from the side-effect note, but nothing is wasted.

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?

Five parameters (three required), no annotations and no output schema means the description must do more. It omits the purpose of task_description's required token prefix, the availability of press_enter and disabling clear_first, and any error or waiting semantics — an agent could invoke it but would be guessing on several behaviors.

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 coverage is 60%: value, selector and task_description are documented, while clear_first and press_enter are not. The description's clearing sentence maps only loosely to clear_first and states clearing as unconditional even though the schema allows it to be disabled, and it never mentions press_enter or the required [AGENT-BROWSER-TASK] token format. Partial compensation, not full.

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?

States a specific verb and resource ('Preenche um campo de formulário') and enumerates the supported element types (input, textarea, select), which tells an agent exactly what it can target. It does not explicitly distinguish itself from browser_click or browser_wait_for, though the overlap is small enough that confusion is unlikely.

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?

There is no guidance on when to use this versus the siblings: nothing about needing the element to exist first (browser_wait_for), navigating before filling, or preferring browser_click for buttons. The agent must infer the workflow entirely from the tool name.

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