browser_select_editable_text

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

With no annotations, the description carries the full burden and does well: it discloses the side effect ('nothing else changes, except that a click giving it focus stays'), the refusal conditions, and the return shape (quoted lines marked ⟦…⟧). It stops short of describing what the selection looks like on the page afterwards or any interaction with subsequent non-toolbar actions.

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?

Front-loaded with the core action and the toolbar follow-up, then the argument rule, then refusals. It is dense with zero filler, though the trailing refusal chain is a long semicolon run that is harder to scan than the lead sentences.

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 10-parameter mutation-free selection tool with no output schema and no annotations, the description supplies what is missing: the return format, the side effect on focus, the argument-selection rule, and a full refusal matrix with remediation. Nothing an agent needs to invoke it correctly is absent.

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 100%, so the baseline is 3, but the description adds a real constraint absent from the schema: exactly one of select, from+to, or all must be given. It also tells the agent how to derive from/to values ('copy the words from the element's snapshot value as for browser_input_text's before/after'), 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 and resource (select words in a text field/editable area) and frames the effect precisely: a drag-like selection so a toolbar button acts on it. It differentiates itself from neighbors by referencing browser_input_text (same from/to copying convention) and browser_click (toolbar click in the same batch, picture caption case).

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?

Explicitly states the use case (selection must precede a bold/colour/link click, possibly in the same batch) and gives an alternative route for each refusal: 'select cell by cell' for cross-cell tables, 'click the picture instead' for captioned images. The when-not list is enumerated rather than implied.

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