Loading ToolBench
MCP server for Chrome DevTools that provides tools for browser automation, debugging, and performance analysis
Chrome DevTools MCP demonstrates strong fundamentals with 24 well-named tools, comprehensive parameter schemas using Zod validation, and consistent tool annotations (category + readOnlyHint). All tools have descriptions and input schemas are properly typed. However, several tools lack parameter descriptions (affecting ~30% of tools), output schemas are not formally documented in the code, and error handling guidance is minimal. The codebase shows professional structure (TypeScript, proper abstractions via ToolDefinition interface) but falls short of A-grade polish in description completeness and recovery guidance.
Clear the value of an input element
Click an element on the page by UID
Close a specific page/tab by index
Get console messages from the selected page
Execute JavaScript code on the selected page
Fill an input element with text
Get network requests from the selected page
Navigate back in the history of the selected page
Navigate forward in the history of the selected page
Output schemas not formally documented. The ToolDefinition interface captures input schemas via Zod but does not specify or document what each tool returns. LLMs cannot plan downstream calls without knowing what fields a response contains (e.g., does take_screenshot return base64 data, a URL, or a file path?). This forces trial-and-error and wastes reasoning cycles.
Parameter descriptions are minimal or missing context. While all parameters have brief descriptions, many lack guidance on format, constraints, or valid ranges. Example: 'timeout' parameters say 'Maximum wait time in milliseconds' but do not specify the default timeout value or the valid range (e.g., 0 means use default, max 60000). This invites LLM errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 15 | - | v1 |
Navigate the selected page to a URL
Handle a dialog (alert, confirm, prompt) on the page
List all open pages/tabs in the browser
Create a new page/tab in the browser
Get information about the currently selected page including title and URL
Press a keyboard key
Reload the selected page
Set CPU throttling rate for the selected page
Set network throttling conditions for the selected page
Set the currently selected page by index
Start recording a performance trace
Stop recording a performance trace and analyze results
Take a screenshot of the selected page
Capture an accessibility snapshot of the selected page
Type text into an element on the page
Error handling and recovery guidance absent. Tool descriptions do not indicate what errors are possible (e.g., 'click' could fail if the element UID is invalid, or the element is no longer present). There is no guidance to the LLM on next steps: should it retry? Call a different tool? Ask the user? This violates the recovery-guide pattern.
Destructive operations (close_page, evaluate, fill) lack confirmation or dry-run support. The tool descriptions do not indicate that these operations are irreversible or warn against accidental misuse. An agent could accidentally close the last open page or execute harmful JavaScript. The code references CLOSE_PAGE_ERROR constant, suggesting awareness of this, but the tool description does not mention this limitation.
Parameter constraints not fully specified in descriptions. The 'format' enum in take_screenshot lists ['png','jpeg','webp'] but the description does not explain when to use each (e.g., 'Use png for lossless screenshots, jpeg for smaller file size'). The 'conditions' enum in set_network_conditions lists presets but does not explain what each represents (bandwidth? latency?). This forces LLMs to guess.
Tool composition chain clarity missing. For example, after calling take_screenshot, where is the image stored? Can it be passed to another tool? The 'uid' parameter in click/type/fill/clear requires a Unique IDentifier, but how do LLMs obtain these UIDs? The description does not say 'Call take_snapshot first to get a list of element UIDs'. This breaks the chain pattern.
Pagination parameters present but guidance lacking. get_network_requests accepts pageSize and pageIdx but does not document the valid range (min/max pageSize), whether it returns a total count, or if there's a next_cursor. This forces agents to guess whether they've retrieved all data.