Loading ToolBench
Model Context Protocol server for browser automation using Selenium WebDriver. Provides tools for launching browsers, navigating pages, interacting with elements, managing cookies, handling windows/frames/alerts, and capturing diagnostics via WebDriver BiDi.
Selenium MCP demonstrates solid tool design with 18 well-named, action-verb tools covering browser automation comprehensively. All tools have descriptions and explicit input schemas with proper types and enums. Tool annotations (readOnlyHint, destructiveHint) are correctly applied. However, descriptions are often terse (many under 100 chars), parameter descriptions lack depth on constraints and formats, and output schemas are not documented. Error handling guidance is absent, tools do not explain recovery paths. Session ID handling via optional parameters is pragmatic but adds cognitive load. No batch operations for common multi-call patterns (e.g., add_labels). Overall: functional and well-structured, but descriptions need expansion for LLM optimization and output schemas should be declared.
adds a cookie to the current browser session. The browser must be on a page from the cookie's domain before setting it.
handles a browser alert, confirm, or prompt dialog
closes a browser session
deletes cookies from the current browser session. Can delete a specific cookie by name or all cookies.
retrieves browser diagnostics (console logs, JS errors, or network activity) captured via WebDriver BiDi
executes JavaScript in the browser and returns the result. Use for advanced interactions not covered by other tools (e.g., drag and drop, scrolling, reading computed styles, manipulating the DOM directly). Also useful for batch-reading multiple element values/states in a single call instead of multiple get_element_attribute calls.
Output schemas not documented. Tools return data but LLMs cannot plan downstream calls or validate responses. E.g., start_browser returns a session_id but this is not declared in an outputSchema.
Descriptions are terse and lack LLM-optimization guidance. Many descriptions under 100 chars (e.g., 'closes a browser session', 'simulates pressing a keyboard key'). Should explain WHEN to use, prerequisites, and what happens. Baseline: 194 chars average for A+ tools.
Parameter descriptions lack constraint details. E.g., 'timeout' params do not specify range (milliseconds? seconds? max value?). 'by' enum values (id, css, xpath, name, tag, class) are not explained, LLMs may not know when to use xpath vs css. Baseline: 72 chars average for param descriptions in A+ tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2025-06-18+ | v2 |
switches focus to a frame or back to the main page
retrieves cookies from the current browser session. Returns all cookies or a specific cookie by name.
gets the value of an attribute on an element. Use this to verify element state. Prefer this over screenshots for validation.
gets the text content of an element
performs a mouse action on an element
navigates to a URL
simulates pressing a keyboard key
sends keys to an element, aka typing. Clears the field first.
launches browser
captures a screenshot of the current page. Prefer using the accessibility://current resource for understanding page content. Use get_element_text, get_element_attribute, or execute_script to verify element state. Only use screenshots when visual layout or styling needs to be verified.
uploads a file using a file input element
manages browser windows and tabs
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., navigate may fail if the URL is invalid or the browser crashes, no recovery path documented.
Generic tool name 'interact' conflates multiple mouse actions (click, doubleclick, rightclick, hover). Splitting into separate tools (click_element, double_click_element, right_click_element, hover_element) would improve clarity and reduce LLM confusion.