Loading ToolBench
MCP server for controlling and interacting with Chrome browser tabs via a WebSocket daemon and Chrome extension
Chrome MCP has 16 tools with consistent naming conventions and moderate schemas, but suffers from critical gaps in output documentation, error handling guidance, and parameter descriptions. Tool names follow verb_noun patterns (get_, extract_, find_, click_, etc.), which is good. However, most tool descriptions lack actionable WHEN-to-use guidance and consequences of side effects. Parameter schemas are present but many lack depth. Output schemas are largely undocumented, callers cannot understand what fields to expect from responses. Error handling is minimal; no recovery guidance. Composition is sound (16 single-purpose tools), but the interface lacks LLM-friendliness in descriptions.
Capture a screenshot of the current viewport
Click an element matching the provided selector or XPath
Execute arbitrary JavaScript code on the page and return the result
Extract structured content from the page including text, headings, links, forms, buttons, and images
Fill a form field or input element with a value
Find elements matching a selector or XPath expression with details about each match
Get detailed information about an element and all its attributes
Output schemas undocumented. No tool description specifies what fields the response contains. Callers cannot plan downstream tool chains without trial-and-error.
Descriptions lack WHEN-to-use guidance and consequence clarity. 'Extract structured content from the page' does not explain when to use extract_content vs get_page_structure vs get_page_source. Descriptions should answer: What does it do? When to use instead of similar tools? What does it return?
Write operations (execute_script, click_element, fill_form, wait_for_navigation, scroll_to_element, press_key) lack explicit state-change warnings. Descriptions do not clearly state these calls have side effects and may be unsafe to retry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Get performance and dimension metrics for the current page
Get the HTML source code of the page with pagination support
Get the hierarchical structure of elements on the current page
Get all visible interactive elements on the page (buttons, links, inputs, etc.)
Simulate a keyboard key press on the page
Scroll the viewport to make an element visible
Search for text on the page with regex or plain text matching
Wait for an element matching a selector to appear on the page
Wait for page navigation to complete
Error handling absent. No tool description provides recovery guidance (e.g., 'If selector matches 0 elements, try a broader CSS query'). LLMs cannot self-correct on failures.
Parameter descriptions too brief or missing rationale. E.g., 'CSS selector or XPath to identify the element' does not explain when to prefer CSS over XPath, or what happens if multiple elements match.
Pagination strategy unclear for large result sets. extract_content and get_page_source support offset/limit, but no tool description specifies the expected total count, next_cursor, or whether results are truncated. LLMs cannot reliably iterate.
Field naming mismatch risk. find_elements parameter is 'selector', but fill_form and click_element also use 'selector' with slightly different semantics (XPath vs CSS default). Descriptions do not clarify these differences, risking LLM confusion.
Long descriptions for options objects (extract_content, search_text) pack many properties without clear rationale. No guidance on common use cases (e.g., 'To extract just text and links, set formsLimit=0, buttonsLimit=0').