Skip to main content
Glama
Sign In
sandboxed-browser-mcp

sandboxed-browser-mcp

by smkamranqadri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Select

browser_select

Picks an option from a native dropdown by visible text and reports on-screen changes. Rejects missing options immediately, listing available choices.

Instructions

Picks an option of a native dropdown by the option's visible text, and reports the changes on screen. An option that is not there is refused at once, with the list of those that are.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ref": "<ref>",
      "option": "<option>"
    },
    "name": "browser_select"
  }
}

Input Schema

NameRequiredDescriptionDefault
refYesRef of the dropdown (e12, f2e7 …), as browser_snapshot or browser_find showed it.
optionYesThe option to pick, by the text it shows.
profileNoWhich browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.default

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • addedInput schema / properties / profile
      Added value: +{
+  "default": "default",
+  "description": "Which browser profile (a separate signed-in session) to use. Leave it out for the default one; name another only when the user's task names it. Profiles: default.",
+  "type": "string"
+}
  2. Changed3 schema fields changedv1.1.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / option / description
      Previous value: -"Option text exactly as shown"New value: +"The option to pick, by the text it shows."
    • changedInput schema / properties / ref / description
      Previous value: -"Element ref from the latest view or browser_find, e.g. e12 (f1e5 inside a frame)"New value: +"Ref of the dropdown (e12, f2e7 …), as browser_snapshot or browser_find showed it."
  3. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses two useful behaviors: it reports on-screen changes, and a missing option is rejected immediately with the list of valid options. This gives the agent a concrete failure mode and recovery path. It still doesn't mention waiting/settling or whether the selection triggers navigation.

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?

Two sentences, no filler, with the primary action stated first and the error behavior second. The failure-with-candidates detail is front-loaded enough to be actionable.

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

Completeness4/5

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

For a three-parameter tool with full schema coverage and no output schema, the description covers what it does, how it matches, and how it fails. The only gap is the post-selection side effects (navigation, network waits), a minor omission given the otherwise complete picture.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented, including the profile default behavior. The description only reinforces that the option is matched by visible text, adding little beyond the schema. Baseline 3 is appropriate.

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

Purpose4/5

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

The description names a specific verb and resource ('picks an option of a native dropdown') and specifies the selection mechanism ('by the option's visible text'). The word 'native' implicitly distinguishes it from custom/JS dropdowns that would need browser_click, though no sibling is named outright.

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

Usage Guidelines3/5

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

Usage is only implied: the agent must infer that this applies to native dropdowns rather than custom ones, and that browser_click is the alternative elsewhere. There is no explicit when-to-use or when-not-to-use statement and no prerequisites mentioned.

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

Deploy Server

Other Tools