Loading ToolBench
MCP server for automated browser control using Puppeteer
Server defines 7 tools with basic schemas and descriptions, but falls short of production quality. All tools have input schemas with type definitions and descriptions present, meeting minimum requirements. However, descriptions are terse (10-50 chars, well below the 50-200 char LLM-optimized baseline), parameter descriptions lack actionable detail, and output schemas are undocumented. No error recovery guidance, no parameter constraints (enums, ranges), and no documentation of side effects for destructive operations. Tool naming follows verb_noun convention (puppeteer_*), which is good, but descriptions do not explain WHEN to use each tool or what happens to browser state. The server maintains global browser/page state without documenting idempotency or retry semantics, creating risk for agents that retry on ambiguous failures.
Click an element on the page
Execute JavaScript in the browser console
Fill out an input field
Hover an element on the page
Navigate to a URL
Take a screenshot of the current page or a specific element
Select an element on the page with Select tag
Descriptions are too terse (10-50 chars vs. 50-200 char baseline). LLMs cannot determine WHEN to use each tool or what distinguishes puppeteer_click from puppeteer_hover from puppeteer_evaluate. Example: 'Click an element on the page' does not explain when to click vs. hover vs. evaluate JavaScript.
No output schema documentation. Callers cannot predict what fields are returned, breaking tool chaining. E.g., puppeteer_screenshot returns image data, but no schema documents the structure or how to reference the screenshot in subsequent calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
No error recovery guidance. If puppeteer_click fails (element not found), the tool returns isError=true with a text message, but does not guide the LLM on next steps (e.g., 'Try puppeteer_screenshot to inspect the page' or 'Verify the selector with puppeteer_evaluate').
Global browser/page state without idempotency guarantees. The server maintains a single browser and page instance across calls. If an agent retries puppeteer_navigate after a timeout, the page may already be navigating, causing race conditions or duplicate side effects. No documentation of retry semantics.
puppeteer_evaluate accepts arbitrary JavaScript with no input validation or sandboxing. This is a critical security risk if the server is exposed to untrusted agents. No mention of code injection prevention or scope limitations.