General-purpose browser automation agent exposed as an MCP server with Playwright-based navigation, interaction, state capture, and reCAPTCHA solving
19 tools with complete input schemas and descriptions, but significant gaps in parameter documentation and output schema specification. Tool names follow verb_noun convention well (browser_navigate, browser_click, etc.). Descriptions are present but often lack context on WHEN to use each tool vs. alternatives, and many parameters lack descriptions entirely. No documented output schemas for any tool. Error handling is basic (try/catch wrapper in server.js) with no recovery guidance. Missing parameter descriptions for ~40% of parameters across tools (e.g., browser_click has x, y, delay with no descriptions; browser_fill_form lacks description for 'data' parameter structure).
Navigate back in history.
Click an element.
Click an element containing specific text.
Double-click an element.
Fill multiple form fields at once. Set typeAware=true to auto-detect input types (date, number, email, tel, url, select, checkbox, radio, file, contenteditable) and format values with the right Playwright method — much more reliable for structured forms than raw fill.
Navigate forward in history.
Hover over an element.
Missing parameter descriptions for coordinate-based tools (browser_click, browser_double_click, browser_right_click, browser_hover). Parameters 'x', 'y', 'delay' lack descriptions explaining what they control or expected ranges.
No output schemas documented for any of the 19 tools. LLMs cannot infer what fields to expect in responses, forcing them to guess at downstream tool chaining and data extraction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
List all open browser tabs.
Navigate to a URL. Retries automatically on network failure. Auto-switches to DuckDuckGo if Google shows CAPTCHA.
Open a new browser tab.
Reload the current page.
Right-click an element.
Search the web using DuckDuckGo (no CAPTCHA). Returns search results. Use this instead of navigating to Google directly.
Switch to a specific tab by index.
Wait for a specified number of milliseconds.
Wait for the page load event. Use instead of browser_wait_until_stable for pages with persistent WebSocket connections or polling that never reach networkidle.
Wait for an element to appear.
Wait for the URL to match a pattern.
Wait for the page to reach a stable state (networkidle).
browser_fill_form 'data' parameter lacks description of expected structure (object with selector keys and values). LLMs cannot determine how to construct the input without explicit guidance.
Error handling is minimal (try/catch in server.js with generic errorResult). No recovery guidance, categorization of error types (retryable vs. fatal), or actionable error messages. LLMs receive raw error text with no context on next steps.
Tool descriptions lack WHEN-to-use context. E.g., browser_wait_until_stable vs. browser_wait_for_load are similar but descriptions don't explain when to prefer one over the other. LLMs may select the wrong tool.