Loading ToolBench
Stealth browser automation for AI agents. Drives real Chrome over raw CDP—no Playwright, no Puppeteer, no WebDriver. Zero runtime dependencies. Passes bot.sannysoft.com 57/57; bypasses Cloudflare's JS challenge.
Veil Browser MCP defines 7 browser automation tools with basic parameter schemas and short descriptions. All tools have names starting with action verbs (veil_*), which is good. However, descriptions are uniformly brief (17-81 chars), falling short of the 194-char production baseline and the 50-200 char LLM-optimized range. Parameter descriptions are minimal or absent. Input schemas exist but lack depth, most parameters are strings with minimal constraint documentation. Output schemas are not documented in the code provided. Error handling guidance is absent. The tool batch operation (veil_batch) combines multiple actions but documentation does not explain conditional logic or failure semantics. Overall, these are functional definitions but lack the rigor expected of production agent tools.
Execute multiple actions in a single round-trip: click, fill, wait, extract, scroll
Click an element by its reference ID
Evaluate a JavaScript expression in the page context and return the result
Fill a text field with human-like typing
Navigate to a URL with optional wait condition
Capture a PNG screenshot of the current page
Capture the accessibility tree (AX snapshot) of the current page
All tool descriptions are under 100 characters, far below the 194-char production baseline. Descriptions lack WHEN to use context, prerequisites, or downstream implications. veil_batch description (17 chars) is critically underdocumented.
Parameter descriptions are absent or one-word. 'Element reference from snapshot' (veil_click.ref) lacks guidance on how to obtain refs or what happens on invalid refs. 'JavaScript expression to evaluate' (veil_eval.expression) does not explain scope isolation, return type handling, or side effects.
No documented output schemas. Callers cannot know what fields to expect from veil_snapshot (AX tree structure), veil_eval (return type), or veil_batch (per-step success/failure semantics). Without output schemas, downstream tool chaining is error-prone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
veil_batch combines 5 actions (clickText, fillText, waitForText, extractMany, scroll) in a single tool. The description does not explain how failures in step N affect step N+1, whether the batch is atomic, or what fields are returned per step. Agents cannot reason about partial success.
No error handling guidance. Tool descriptions do not explain retryable vs fatal errors, what errors are possible, or recovery steps. E.g., what happens if veil_click is called with an invalid ref? Does veil_goto timeout and how should the agent respond?
Parameter 'ref' (veil_click, veil_fill) is undescribed beyond 'Element reference from snapshot'. Agents do not know: Is it a CSS selector, a numeric ID, an XPath? How do they map snapshot output to a valid ref? Are refs stable across navigations?
veil_batch 'steps' parameter is an array of objects with action enum and generic 'args' property. No schema documents the shape of args for each action type. Agents must guess the structure of clickText args vs fillText args.
veil_goto timeout parameter is a number but lacks min/max bounds, units clarity (milliseconds stated, but error behavior at zero or negative is undocumented), and guidance on reasonable values.