Loading ToolBench
MCP server that lets coding agents drive a real browser.
Strong browser automation toolkit with well-structured tool definitions. All 14 tools have descriptions and input schemas with typed parameters. Naming follows verb_noun convention (browser_*). However, descriptions are terse (avg ~80 chars, below the 194-char baseline), parameter descriptions lack depth, and output schemas are not documented. Error handling guidance is minimal. The policy layer tools (browser_propose_action, browser_approve_action) are sophisticated but their descriptions assume domain knowledge of envelope digests and approval workflows without explaining when/why an agent would use them.
Mint a one-time approval bound to a previously-proposed envelope digest. The approval is keyed by the SHA-256 envelope digest, the approver identity, and a random nonce; it expires after the configured TTL. Replays of the same approval id are rejected.
Click an element identified by a snapshot ref, CSS selector, or x+y coordinates. Prefer `ref` from browser_snapshot.
Drag from one element to another. Accepts snapshot refs or selectors.
Run a JS expression in the page context and return its JSON-serializable result.
Replace an input value via Playwright's fill() — accepts a selector or a snapshot ref.
Hover an element. Accepts a snapshot ref or a selector.
Output schemas not documented. Tools return results but LLMs cannot predict field structure, forcing trial-and-error parsing. E.g., browser_snapshot returns a 'ref' token but the response format is not specified.
Parameter descriptions are minimal (avg ~30 chars). E.g., browser_click's 'ref' param says 'Snapshot ref token' but does not explain what a ref is, how it's obtained, or when to use it vs selector/coordinates. LLMs cannot infer context.
Policy layer tools (browser_propose_action, browser_approve_action) lack context for when an agent should use them. Descriptions assume knowledge of 'envelope digests', 'approval workflows', and 'risk classification' without explaining the approval gate pattern or when approval is required.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Open a URL in the browser.
Press a non-text key (Enter, Tab, Escape, arrows, etc.).
Build a canonical proposed-action envelope for a primitive tool call, classify its risk, and return the envelope + SHA-256 digest. If approval is required, call browser_approve_action and then invoke the primitive tool with the returned approval id and proposal id.
Capture a PNG screenshot. Returns base64 or saves to disk if savePath is set.
Select an <option> by value or label. Accepts a snapshot ref or a selector.
Return the AI-oriented accessibility snapshot for the current page. Each node carries a generation-bound `ref` token (e.g. `[ref=p2s3_r7]`) that can be passed back into browser_click/browser_type/etc. Refs are invalidated by navigation, rerendered/recycled target nodes, or a newer snapshot.
Type text into the focused, matched, or ref-targeted element using keyboard events.
Wait for a condition or timeout.
No error handling guidance. Tools do not document what errors are possible, whether they are retryable, or what the LLM should do next. E.g., browser_navigate could fail with 'URL unreachable' or 'timeout' but recovery steps are not specified.
Mutually exclusive parameters not documented. browser_click accepts 'ref', 'selector', and 'x+y' coordinates, all optional. LLMs will not know which to prefer or whether passing multiple is an error.