web_type

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

With no annotations at all, the description carries the full behavioral burden. It does add real value by disclosing submit mechanics — it prefers submitting the enclosing form and only falls back to a synthetic Enter key when no form exists. However, it is silent on failure behavior when the selector matches nothing, whether existing text is cleared, whether the field is focused or scrolled into view, and whether it waits for the element to appear.

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?

A single front-loaded sentence with the action first and qualifications in parentheses; nothing is wasted. Slightly nested parentheticals cost a little readability but the structure is otherwise tight.

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?

For a 3-parameter browser-interaction tool with no annotations and no output schema, the description covers the core action and the submit side effect adequately. It still leaves out the post-call outcome (does it return the filled value, a success flag, or throw on a bad selector) and the failure modes an agent needs to recover from.

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, but the description genuinely enriches the `submit` parameter beyond the schema's terse '填完是否提交，默认 false' by explaining the mechanism (form submit preferred, Enter-key fallback otherwise). That detail tells the agent what side effect to expect, which the schema does not.

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 (fill) plus the target resource (an input box on the current page) and the addressing mechanism (CSS selector). The 'current page' scoping implicitly separates it from web_open/web_search navigation tools, though no sibling is named explicitly.

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?

Usage is implied by 'fill content into an input box on the current page' — an agent can infer this is for text entry rather than clicking or reading. There is no explicit when-not guidance, no mention of alternatives such as web_click for buttons or web_open for navigating first, and no stated preconditions (e.g. that the element must already exist in the DOM).

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