Loading ToolBench
Fast browser automation MCP server for LLMs — persistent Chromium, ref-based interaction, cookie migration
Pilot MCP demonstrates solid tool design with comprehensive parameter schemas and detailed descriptions. All three tools (pilot_snapshot, pilot_snapshot_diff, pilot_find) have well-structured Zod schemas with type definitions and parameter descriptions. Descriptions are detailed (200-400 chars) and explain WHEN to use each tool. However, output schemas are not formally documented, responses are inferred from code (text content arrays). Error handling is present but generic ('Timeout: The page is too complex'). Tool naming follows verb_noun convention clearly. No security concerns detected (read-only tools, no credential parameters). Composition is clean, each tool has a single responsibility and tools chain via @eN refs.
Find an element by visible text, label, placeholder, or role — without running a full snapshot. Use when you know what you want to click or fill but don't need to see the entire page tree. Returns a @eN ref immediately usable by pilot_click, pilot_fill, pilot_hover, and other interaction tools. Saves tokens compared to pilot_snapshot when you only need one element.
Capture an accessibility tree snapshot of the page with @eN refs for element selection. Use when the user wants to see the page structure, find elements to interact with, or get refs for click/fill/hover. This is the primary way to understand what is on the page. Refs from this snapshot are used by pilot_click, pilot_fill, pilot_hover, pilot_select_option, and most other interaction tools.
Compare the current page state against the previously captured snapshot, showing a unified diff of what changed. Use when the user wants to verify the effect of an action (click, fill, navigation), check if dynamic content loaded, or see what changed on the page without re-reading the entire snapshot. The first call stores a baseline; subsequent calls diff against it.
Output schemas not formally documented. Responses return text content arrays, but LLMs cannot infer structure of returned text (is it JSON, plain text, structured refs?). Downstream tools expecting @eN refs need explicit documentation of ref format.
Error messages are generic and lack recovery guidance. 'Timeout: The page is too complex or unresponsive' does not tell the LLM what to do next (retry? reduce max_elements? change selector?). Missing actionable error classification.
pilot_find has mutually exclusive parameters (text, label, placeholder, role) but descriptions do not state this. LLMs may pass multiple parameters, causing ambiguous behavior. Needs explicit 'pass exactly one of' constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
No pagination or result limits documented for pilot_find. If search returns many matches, response could be large. Missing limit parameter and guidance on result truncation.
pilot_snapshot_diff lacks documentation of what 'baseline' means and how long it persists. Is it per-session? Per-browser? Per-call? Ambiguity could cause LLMs to misuse the tool across unrelated snapshots.