Skip to main content
Glama
andresolbach

nodriver-mcp-server

Choose a select option

select_option

Pick an option from a dropdown menu by visible label, value, or position. When no match is found, it lists the actual options so you can correct the choice and retry.

Instructions

Choose an option in a , by value, visible label or index.

fill also works on a , but only matches the value attribute, which is not what a snapshot shows you — so it had to be guessed. This matches what you can actually see, and when nothing matches it lists the real options instead of only saying no.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesElement uid from the most recent take_snapshot, e.g. "4_12". uids are invalidated whenever the page changes — if you get "unknown uid", take a fresh snapshot and retry with the new uid.
optionYesThe option to choose. Matched against the value attribute first, then the visible label, then — if it is a plain number — the position in the list. A failure names every option the <select> actually has.
browserNoWhich browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.default
include_snapshotNoAppend a fresh page snapshot to the response. Worth it when this action changes the page and take_snapshot would be your next call anyway — it saves a round trip, at the cost of a much larger response.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already convey that this is not read-only and not idempotent, so the safety profile is covered. The description adds meaningful behavioral detail beyond the annotations: it states the tool matches what can actually be seen, and that on failure it lists the real options rather than returning a bare 'no'. This informs the agent about error behavior and matching strategy without contradicting the annotations.

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

Conciseness5/5

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

The description is compact and front-loaded: the first sentence states exactly what the tool does, and the second paragraph earnestly explains when it is needed and how failures behave. Every sentence carries useful information, with no filler or repetition of the structured schema.

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 tool with a rich input schema, useful annotations, and an output schema, the description covers everything an agent needs to call it correctly: purpose, matching strategy, alternative comparison, and failure behavior. Nothing essential is missing, and the description complements rather than duplicates the structured fields.

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

Parameters4/5

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. The description adds value by framing the 'option' parameter's matching order in practical terms and explaining why the value-attribute-only approach of 'fill' is insufficient for snapshot-driven workflows. This goes beyond simply restating parameter names and enriches the agent's understanding of how the parameters should be used.

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?

The description uses a specific verb and resource: 'Choose an option in a <select>', and names the matching keys (value, visible label, or index). It also differentiates itself from the sibling 'fill' by explaining the crucial limitation of fill on selects, making the tool's unique role immediately clear.

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?

The description explicitly addresses the main alternative, 'fill', and gives the when-not-to-use-it reasoning: fill only matches the value attribute, which is not what snapshots show. It then explains why this tool is preferable when working from a snapshot and what happens when no option matches, providing concrete guidance for choosing it over the alternative.

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