Loading ToolBench
Native messaging host that bridges Chrome browser automation tools via MCP protocol. Provides tools for browser control, network capture, performance analysis, recording/replay flows, and web interaction.
Chrome MCP Bridge presents 8 tools with varying definition quality. Strengths: all tools have descriptions (10-200 chars each, mostly adequate), verb-action naming conventions (get_, chrome_, performance_, record_), and JSON Schema input definitions visible. Weaknesses: parameter descriptions are inconsistent, some tools like chrome_read_page have detailed param docs; others like get_windows_and_tabs and chrome_network_capture have zero required parameters with no explanation of what they actually do or return; output schemas are completely undocumented across all tools, forcing LLMs to infer response structure; no error handling guidance; no tool annotations (readOnlyHint/destructiveHint). The tool chrome_computer combines multiple interaction modes (click, type, screenshot, drag) in one tool, borderline acceptable for a unified browser interaction surface, but pushes single-responsibility limits. Baseline: 549 production tools average 4 params per tool, these range 0 - 7, which is reasonable. Description lengths average 194 chars; these tools range 50 - 250 chars, mostly compliant. However, the complete absence of output schema documentation is a critical gap.
Use a mouse and keyboard to interact with a web browser, and take screenshots. * Whenever you intend to click on an element like an icon, you should consult a read_page to determine the ref of the element before moving the cursor. * If you tried clicking on a program or link but it failed to load, even after waiting, try screenshot and then adjusting your click location so that the tip of the cursor visually falls on the element that you want to click. * Make sure to click any buttons, links, icons, etc with the cursor tip in the center of the element. Don't click boxes on their edges unless asked.
Capture network requests and responses with filtering and logging options
Get an accessibility tree representation of visible elements on the page. Only returns elements that are visible in the viewport. Optionally filter for only interactive elements. Tip: If the returned elements do not include the specific element you need, use the computer tool's screenshot (action="screenshot") to capture the element's on-screen coordinates, then operate by coordinates.
Get all currently open browser windows and tabs
Provides a lightweight summary of the last recorded trace. For deep insights (CWV, breakdowns), integrate native-side DevTools trace engine.
Output schemas completely undocumented across all 8 tools. LLMs must infer response structure, leading to parsing errors and hallucination. Pattern:tool mandates documented return types.
Tools get_windows_and_tabs and chrome_network_capture claim optional input parameters ('filtering and logging options') but schema shows zero required and zero documented properties. Descriptions contradict schemas.
chrome_computer action parameter has enum values listed in description string ('left_click | right_click...') instead of formal JSON Schema enum constraint. Parser cannot enforce valid actions; LLMs must read prose.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Starts a performance trace recording on the selected page. Optionally reloads the page and/or auto-stops after a short duration.
Stops the active performance trace recording on the selected page.
Run a recorded flow by ID with optional variables and run options. Returns a standardized run result.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in input schemas. Agents cannot automatically determine side-effect safety. Tools are marked READ_ONLY or WRITE in external metadata but not in MCP schema.
No error handling guidance in any tool description. If a tool fails (e.g., 'trace already active', 'element not found'), LLM receives no recovery hint. Pattern:recovery-guide requires error categorization.
record_replay_flow_run 'args' parameter described as 'Variable values for the flow (flat object of key/value)', no documentation of which keys are valid, expected types, or constraints. LLMs must guess structure.