wavexis_select_option

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

Annotations already indicate destructiveHint=true, so the description is not required to repeat that. However, it adds minimal behavioral context: it mentions selecting by value and returning a JSON 'ok' status. It does not discuss side effects (e.g., triggering change events), error handling, or what happens if the option or element is missing. With annotations providing some safety profile, a score of 3 is appropriate.

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?

The description is concise (two sentences plus Args/Returns sections) and front-loaded with the main action. However, it could be slightly better structured by grouping related parameters or providing a usage example. It is not verbose, which is good, but the brevity sacrifices detail in other areas.

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 tool's complexity (seven parameters, some optional) and the availability of an output schema, the description is insufficient. It does not explain the role of optional parameters like url, backend, or headless, nor does it provide usage context (e.g., when to set wait_timeout). The description covers only the essential parameters, leaving the agent to guess about others.

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 0% per context signals, meaning the tool's description does not explain the parameters beyond the schema's own descriptions (which cover only 'selector' and 'value'). The description merely lists 'selector' and 'value' without adding meaning. Optional parameters like url, backend, headless, session_id, wait_timeout are entirely undocumented in the description, leaving the agent uninformed.

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 clearly states the tool's purpose: 'Select an option in a <select> element by value.' This is a specific verb+resource combination that distinguishes it from sibling tools like wavexis_click (general click) and wavexis_fill (form fill). The tool's niche is well-defined.

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?

The description implies usage for selecting <select> options by value, but it does not explicitly state when to use this tool versus alternatives (e.g., wavexis_fill for other form fields). There is no mention of prerequisites (e.g., page load, element existence) or when not to use it (e.g., if the select requires text-based selection).

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