Loading ToolBench
MCP server for browser automation using Puppeteer with configurable options
MCP Configurable Puppeteer has 7 tools with complete input schemas and descriptions present, but the definitions show significant gaps that limit production readiness. All tools use verb_noun naming (puppeteer_*), which is appropriate. However, most tool descriptions are extremely brief (10-30 characters), falling far below the baseline average of 194 characters and the ideal 50-200 character range for LLM optimization. Parameter descriptions are inconsistent in detail. Error handling provides basic try-catch with isError flags, but lacks recovery guidance or categorization as retryable vs. fatal. No parameter validation beyond presence checks (e.g., width/height default to 800x600 but have no explicit bounds). Output structures are minimally documented inline. The tool set itself is well-composed (each does one thing), but the documentation does not meet production standards for agent optimization.
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
Tool descriptions are far too brief (10-30 characters vs. baseline 194 chars). 'Navigate to a URL' and 'Click an element on the page' lack context about when/why to use each tool, prerequisites, or what the agent should expect. LLMs struggle to select tools without richer descriptions.
No parameter descriptions for required inputs. 'url' in puppeteer_navigate has no description. 'script' in puppeteer_evaluate has no format guidance (is it a single statement? full function body? can it use async/await?). LLMs cannot infer constraints from names alone.
Numeric parameters (width, height) lack explicit bounds or validation. Currently default to 800x600 but have no documented min/max. An LLM could pass width: 99999 or negative values without rejection. No enum constraints for discrete valid choices.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Error responses are minimal. puppeteer_click returns 'Failed to click X: <error message>' but does not categorize the error as retryable (selector not found) vs. fatal (browser crashed). No guidance on recovery (e.g., 'Try taking a screenshot first to see current page state').
Global state (browser, page, consoleLogs, screenshots map) is maintained in module scope. MCP protocol assumes stateless handling per request. If multiple concurrent requests arrive, they will share browser state and conflict. No per-session isolation or request scoping.
Output schema is not formally documented. puppeteer_screenshot returns TextContent + ImageContent inline; no schema documentation for caller. Tool result structure (isError, content array) is MCP-standard but the actual data structure (e.g., screenshot metadata, console log format) is implicit, not explicit.
puppeteer_evaluate allows arbitrary JavaScript execution. No input validation, escaping, or restriction on what script can do. An LLM could be tricked into executing malicious code (e.g., exfiltrating page data, modifying DOM). This is a severe code injection risk.