Loading ToolBench
MCP server that drives your already-running, already-logged-in Chrome via a companion extension using chrome.debugger/CDP. Clean-room equivalent of the Codex/ChatGPT desktop Chrome tool.
Chrome-bridge-mcp has 19 well-named tools with consistent verb_noun patterns (browser_*). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present and typed for all tools. However, descriptions are terse and lack context on WHEN to use each tool, prerequisites, or recovery guidance. Parameter descriptions are minimal (e.g., 'The tab ID to attach to (optional, defaults to active tab)' is good, but most lack format/constraint details). Output schemas are not documented, LLMs cannot predict what browser_snapshot or browser_evaluate return. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Security: browser_evaluate accepts arbitrary JavaScript, creating injection risk if untrusted input reaches it. No audit logging visible. Composition is strong, tools chain well (snapshot → click/type → screenshot) and are single-responsibility. Overall: solid naming and basic structure, but descriptions need depth, output schemas must be documented, and error handling is critical for production use.
Attach to a specific tab to control it. If no tabId is provided, attaches to the active tab.
Click on an element identified by a ref from browser_snapshot
Close a specific tab by its ID
Detach from the currently controlled tab, releasing control and removing the debugging banner
Evaluate arbitrary JavaScript in the page context and return the result
Focus on an element identified by a ref
Get an attribute value from an element identified by a ref
Output schemas not documented. browser_snapshot, browser_screenshot, browser_evaluate, and browser_tabs return complex structures (refs, images, JSON) but LLMs cannot predict field names or types. This forces agents to guess downstream parameter mappings.
No error handling guidance. Tools lack recovery hints (e.g., 'If element not found, call browser_snapshot first to refresh refs'). No indication of retryability or whether errors are user-fixable vs fatal.
browser_evaluate accepts arbitrary JavaScript expressions with no input validation or sandboxing. If untrusted input (e.g., from a webpage) reaches this tool, it enables code injection. Requires sanitization or explicit user confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Extract text content from an element identified by a ref
Open a new tab with an optional URL
Press a keyboard key or key combination
Take a screenshot of the current viewport
Scroll the page or an element
Select all text in a focused input field
Set an attribute value on an element identified by a ref
Take a snapshot of the current page state, including visible elements with refs for interaction
List all open tabs in the browser with their IDs, titles, and URLs
Type text into a focused input field or element
Wait for an element matching a selector to appear on the page
Wait for the page to navigate to a new URL
Descriptions lack context on WHEN to use each tool. E.g., browser_snapshot vs browser_screenshot, when does an LLM choose one over the other? Descriptions should explain prerequisites and typical workflows.
No pagination or result limits documented. browser_tabs could return hundreds of tabs; no indication of max results, pagination support, or how to handle large result sets.