Skip to main content
Glama
JustasMonkev

MCP Accessibility Scanner

browser_select_option

Destructive

Automates the selection of dropdown options in web accessibility scans, ensuring accurate interaction with specific elements for WCAG compliance testing. Ideal for precise dropdown value validation.

Instructions

Select an option in a dropdown

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
elementYesHuman-readable element description used to obtain permission to interact with the element
refYesExact target element reference from the page snapshot
valuesYesArray of values to select in the dropdown. This can be a single value or multiple values.

Implementation Reference

  • Defines the Zod input schema and tool metadata (name, title, description, type) for the browser_select_option tool. It extends the shared elementSchema with a 'values' array parameter.
    const selectOptionSchema = elementSchema.extend({
      values: z.array(z.string()).describe('Array of values to select in the dropdown. This can be a single value or multiple values.'),
    });
    
    const selectOption = defineTabTool({
      capability: 'core',
      schema: {
        name: 'browser_select_option',
        title: 'Select option',
        description: 'Select an option in a dropdown',
        inputSchema: selectOptionSchema,
        type: 'destructive',
      },
  • The core handler function that executes the tool. It resolves the element locator from the provided ref, generates equivalent Playwright code for the response, includes a page snapshot, and performs the selectOption action on the locator using the provided values.
      handle: async (tab, params, response) => {
        response.setIncludeSnapshot();
    
        const locator = await tab.refLocator(params);
        response.addCode(`await page.${await generateLocator(locator)}.selectOption(${javascript.formatObject(params.values)});`);
    
        await tab.waitForCompletion(async () => {
          await locator.selectOption(params.values);
        });
      },
    });
  • Registers the browser tools (including browser_select_option) by initializing the tools list via filteredTools(config) in the BrowserServerBackend, which provides them to the MCP server via listTools() and callTool().
      this._tools = filteredTools(config);
    }
  • src/tools.ts:38-56 (registration)
    Aggregates all browser tool modules, including snapshot.ts which defines browser_select_option, into the allTools array. filteredTools filters this list based on config for the backend.
    export const allTools: Tool<any>[] = [
      ...common,
      ...console,
      ...dialogs,
      ...evaluate,
      ...files,
      ...form,
      ...install,
      ...keyboard,
      ...navigate,
      ...network,
      ...mouse,
      ...pdf,
      ...screenshot,
      ...snapshot,
      ...tabs,
      ...wait,
      ...verify,
    ];
Behavior3/5

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

Annotations provide critical behavioral hints: destructiveHint=true (indicating it modifies state) and openWorldHint=true (suggesting unpredictable outcomes). The description adds minimal context beyond this, stating the action but not elaborating on risks like page reloads or validation errors. It doesn't contradict annotations, but with annotations covering safety aspects, the description's value is limited to confirming the basic action without rich behavioral details.

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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Select an option in a dropdown'), making it immediately scannable. Every word earns its place, and there's no redundancy or unnecessary elaboration.

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

Completeness3/5

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

For a destructive tool with no output schema, the description is minimally adequate. Annotations cover key behavioral traits (destructive, open-world), and the schema fully documents parameters. However, the description lacks context about error conditions, what happens on success, or integration with other tools like browser_snapshot. It meets basic needs but leaves gaps for safe and effective use.

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%, with clear descriptions for all three parameters (element, ref, values). The description adds no parameter-specific information beyond what the schema already provides. It implies 'values' usage but doesn't clarify syntax or multi-select behavior. Given high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.

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 'Select an option in a dropdown' clearly states the verb ('Select') and resource ('option in a dropdown'), making the purpose immediately understandable. It distinguishes this tool from siblings like browser_click or browser_type by specifying dropdown interaction, though it doesn't explicitly contrast with all similar tools like browser_handle_dialog. The description is specific but could be more precise about its unique role among browser interaction tools.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page snapshot from browser_snapshot first), when to prefer it over other selection methods, or any limitations. With many sibling tools for browser interaction, this lack of context leaves the agent guessing about appropriate usage scenarios.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JustasMonkev/mcp-accessibility-scanner'

If you have feedback or need assistance with the MCP directory API, please join our Discord server