This MCP server has severe definition quality issues. Three tools are defined, but all lack proper parameter descriptions and output schemas. Tool names follow basic verb-noun conventions but descriptions are minimal (10-30 chars, well below the 50-200 char optimum for LLM use). No input parameter descriptions are visible in the schema definitions. No output schemas are documented. Error handling is absent. The server appears to be a thin wrapper around Playwright without substantial MCP-specific design work.
Tools (3)
browser_closewritesource verified43/100
Close the browser session
browser_evaluateread onlysource verified32/100
Evaluate a function in the browser context and return the result
All tools lack parameter descriptions. The 'url' parameter in browser_navigate has no guidance on format (full URL? path? special handling?). The 'function' parameter in browser_evaluate has no explanation of JavaScript dialect, sandboxing, return type expectations, or security constraints. LLMs cannot infer parameter meaning from names alone.
No output schemas documented for any tool. LLMs do not know what fields to expect from browser_navigate, browser_evaluate, or browser_close responses. This prevents downstream tool composition and forces LLMs to guess at response structure.
Tool descriptions are too short (10-30 characters, far below the 50-200 char baseline). 'Navigate browser to a specified URL' (30 chars) lacks context: what if the URL is invalid? What happens on timeout? What is returned? 'Evaluate a function in the browser context and return the result' (65 chars) does not explain return type, error handling, or JavaScript version.
Recommendations
Expand tool descriptions to 100-200 characters. Example for browser_navigate: 'Navigate the browser to the specified URL. Waits for page load (up to 30s). Returns the final URL and page title. Throws error if URL is invalid, unreachable, or load times out. Common retry cases: connection refused (check URL), SSL errors (may resolve on retry), redirects (automatic).'
Add detailed parameter descriptions. For 'url': 'Full HTTP(S) URL to navigate to. Must include scheme (http:// or https://). Max 2048 chars. Will follow redirects. Throws on invalid scheme, malformed URL, or unreachable host.' For 'function': 'JavaScript code as a string (function body or arrow function). Must be synchronous and return a JSON-serializable value (string, number, boolean, object, array). No promises, async/await, or side effects. Timeout: 5s. Returns the result; throws on syntax error or timeout.'
Document output schemas explicitly. Add a 'Returns' section to each description: browser_navigate returns {url: string, title: string, status: number}; browser_evaluate returns {result: any, type: string}; browser_close returns {success: boolean}.
Add validation and constraints. browser_navigate: validate URL format in the description ('Must match https?://[host]:[port]?[/path]?[?query]?[#fragment]?'). browser_evaluate: document max script length (e.g., 10KB), execution timeout (5s), and that only JSON-serializable returns are supported.
Add error handling examples. 'If browser_navigate fails with 'ECONNREFUSED', the URL host is unreachable, check spelling. If 'ERR_SSL_PROTOCOL_ERROR', the domain has SSL issues; try again or use a different URL. If 'TIMEOUT', the page took >30s to load; may retry with a simpler page.'
browser_evaluate accepts arbitrary JavaScript with no constraints, validation, or security description. LLMs may pass code that: causes infinite loops (blocking the browser), accesses restricted APIs, or breaks the page state. No mention of timeouts, sandboxing, or safe return types (primitives vs complex objects vs large data).
No error handling guidance. If browser_navigate fails (network error, timeout, invalid URL, SSL certificate issue, redirect loop), the response likely contains only an error code. No recovery steps for the LLM. If browser_evaluate throws an exception, how is it surfaced? Can the LLM retry?
browser_close has an empty input schema ({}). While correct, the description is only 26 characters and explains nothing about state cleanup, whether pending operations are aborted, or what happens if called twice.
No mention of tool idempotence, retryability, or side effects. browser_navigate and browser_evaluate have side effects (page state changes, network calls). browser_close is destructive. LLMs need explicit guidance on whether these can be safely retried.
Composition gaps: browser_evaluate returns a result, but the schema does not specify structure. If browser_evaluate returns a JSON object with nested fields (e.g., page title, URL, element count), how does the LLM know which fields are available? This breaks tool chaining.
browser_evaluate
Clarify idempotence and retryability. 'browser_navigate is idempotent: calling it twice with the same URL is safe and yields the same result. browser_evaluate is NOT idempotent if the JS modifies page state (e.g., clicks, form input); document expected state before calling. browser_close is destructive and non-idempotent; calling twice fails.'
Add resource/risk context. Mark browser_navigate and browser_evaluate as WRITE operations (they modify browser state). Mark browser_close as DESTRUCTIVE. This signals to LLMs that these calls have consequences.
Consider splitting browser_evaluate into safer variants: browser_query_selector (returns elements matching a CSS selector), browser_get_text (returns visible page text), browser_get_links (returns href list), plus a generic browser_evaluate for power users. This reduces misuse surface.
Add rate/concurrency limits to descriptions if applicable: 'Only one browser instance is active; concurrent calls queue. Max 100 evaluate calls per browser session.'
Document the browser session lifecycle. 'A browser session is created on first call and remains open until browser_close is called. All navigate and evaluate calls operate on the same browser state. Closing the browser invalidates the session; subsequent calls will fail unless the client reconnects.'