Airbrowser

Overview Schema Source Related Servers Discussions Admin

select_option

Select a choice from a native HTML dropdown by matching visible text, value attribute, or index. Provide a CSS selector to locate the dropdown and specify the desired option.

Instructions

Select an option from an HTML dropdown.

Args: dropdown_selector: CSS selector identifying the element.

value: The option's visible text, its HTML value attribute, or its
    0-based index, depending on by.

by:
    - "text": Match the option's visible text.
    - "value": Match the option's HTML value attribute.
    - "index": Match the option's 0-based position. Both integer and
      numeric-string values are accepted.

Raises: An error when the dropdown or requested option cannot be found.

This tool is for native elements. For custom JavaScript dropdowns made from div/button/list elements, use click_element or other element-interaction tools instead.

Input Schema

TableJSON Schema

Name	Required	Default
`by`	No	text
`value`	Yes
`dropdown_selector`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.15.0Sep 15, 2026

TDQS

A4.7/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden. It discloses the error behavior ('Raises: An error when the dropdown or requested option cannot be found'), which is valuable failure-mode information. However, it doesn't cover whether the selection triggers change events, whether it waits for options to load, or what the success response looks like (though an output schema exists, reducing that need).

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

Conciseness4/5

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

Well-structured with Args and Raises sections, front-loaded purpose statement. The documentation is thorough but slightly verbose with the args restating what a schema normally covers; still, every sentence adds value given 0% schema coverage.

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

Completeness5/5

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

For a 3-param interaction tool with no annotations and 0% schema coverage, the description covers purpose, all parameter semantics, error behavior, and sibling routing. An output schema exists so return values needn't be explained. Nothing an agent needs to call this correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate. It thoroughly documents the semantics of 'by' (text/value/index) and explains what 'value' means for each mode, including that both integer and numeric-string index values are accepted. This goes well beyond the bare schema.

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

Purpose5/5

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

States a specific verb (select) and resource (option from an HTML <select> dropdown), and explicitly distinguishes this native-select tool from custom JS dropdowns. An agent can immediately tell it apart from click_element or hover_action.

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

Usage Guidelines5/5

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

Explicitly names the when-not condition ('This tool is for native <select> elements') and routes custom JS dropdowns to click_element or other element-interaction tools. This is the strongest possible sibling differentiation.

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