This is a browser automation MCP server with 13 tools. Strengths: all tools have descriptions (94 chars avg), all parameters have type definitions and descriptions, schema constraints are present (enum values for browser parameter). Weaknesses: descriptions are generic and lack specificity about WHEN to use each tool; no output schemas documented; no error handling guidance visible; parameters lack detail on constraints (e.g., what CSS selector formats are valid, what JavaScript will succeed vs fail); composition is good (tools are granular) but tool descriptions don't guide the agent on typical call sequences. The server is well-structured and functional for basic browser control, but descriptions do not optimize for LLM decision-making, they describe WHAT the tool does but not WHEN or WHY to prefer it over alternatives, and omit examples of common failure modes and recovery paths.
Tools (13)
browser_clickwritesource verified70/100
Click an element by its selector
browser_click_atwritesource verified68/100
Click at specific viewport coordinates
browser_closewritesource verified72/100
Close a browser (main or support)
browser_evaluateread onlysource verified68/100
Evaluate JavaScript code in the page context and return the result
browser_navigateread onlysource verified72/100
Navigate to a URL and wait for the page to load
browser_openwritesource verified72/100
Open a browser (main or support) with optional seed, proxy, or profile to control identity
Descriptions are generic and task-agnostic. They state WHAT the tool does but not WHEN to use it or HOW it differs from similar tools. For example, 'Click an element by its selector' does not explain when to prefer browser_click over browser_click_at, or what happens if the element is off-screen, not clickable, or covered by an overlay. LLMs cannot optimize tool selection without this context.
No output schemas documented. Tools like browser_snapshot, browser_read_html, and browser_evaluate return complex data (interactive elements with selectors, HTML trees, JavaScript results) but the spec does not describe the shape, field names, or structure. LLMs cannot plan follow-up calls or extract the right data without knowing what fields are returned.
Enhance tool descriptions to include WHEN and WHY. For browser_click: 'Click an element by CSS selector. Use when you know the element's selector. Prefer over browser_click_at when targeting by class, ID, or structure. Fails if selector does not match, element is hidden, or covered by overlay, use browser_evaluate to check visibility first.'
Document output schemas for all tools. For browser_snapshot: 'Returns an array of interactive elements: [{selector: string, tagName: string, text: string, boundingBox: {x, y, width, height}, attributes: object}, ...]. Respects z-order and visibility; excludes hidden elements.' For browser_evaluate: 'Returns the result of script.toString() for serializable types (string, number, boolean, array, object) or null if not serializable.'
Add error handling guidance. For browser_navigate: 'Returns HTTP status and final URL. If status >= 400, the page may not have loaded. If URL changed unexpectedly, navigation hit a redirect chain or error page. If wait_until times out, the page may be hanging, retry with shorter timeout or use browser_take_screenshot to check progress.'
Clarify parameter constraints. For selector params: 'Valid CSS selectors: tag name (div), ID (#myId), class (.myClass), attribute ([data-test=value]), combinator (div > span), pseudo-element (::before). Multiple matches use the first. Escaping: use CSS.escape() for non-standard characters.' For script param: 'JavaScript runs in the page context with access to DOM, window, console. Return non-serializable objects as JSON.stringify() or string representation. Errors throw and abort the call.'
Score history
Overall score trend
First recorded score · v2 rubric
64/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
C
64
2026-07-28+
v2
source verified
67/100
Read the HTML content of the current page
browser_select_optionwritesource verified72/100
Select an option in a select element
browser_snapshotread onlysource verified68/100
Get the snapshot of the current page with all interactive elements and their selectors
No error handling guidance. Descriptions do not explain what errors can occur (e.g., 'selector not found', 'element not clickable', 'JavaScript syntax error') or how to recover. An LLM encountering a 404 or timeout has no actionable next step.
Parameter descriptions lack specificity. 'CSS selector of the element to click' does not explain valid selector syntax, what happens if multiple elements match, or whether pseudo-elements are supported. 'JavaScript code to evaluate' does not specify whether the script runs in the page context or server context, whether it can access DOM, or what happens if it throws an error.
No pagination or limit constraints documented for tools that may return large results (e.g., browser_snapshot returning all interactive elements on a complex page, browser_read_html returning the full HTML tree). If a page has thousands of elements, context window exhaustion is likely without a cap or pagination mechanism.
browser_watch description is vague: 'Watch the page for changes and stream updates via screencast' does not clarify what changes trigger updates, how long the watch runs, whether streaming is bidirectional, or how the agent consumes the screencast output.
browser_watch
Cap and document result sizes. For browser_snapshot and browser_read_html: 'Returns up to 1000 interactive elements/nodes. For complex pages, use browser_evaluate to query specific subtrees via querySelectorAll or getElementsByClassName.'
Clarify browser_watch. 'Streams a live screencast of page changes. Returns updates every 100ms or when DOM mutations occur. Runs indefinitely until client closes the stream. Use to monitor long-running operations (form submissions, file uploads) without polling.'
Add composition guidance in tool descriptions. Group related tools and explain typical call sequences: 'Typical workflow: browser_take_screenshot → identify target → browser_click or browser_type → browser_snapshot to verify state change.'
For browser_open, document the effect of each parameter: 'seed: reproducible browser fingerprint for multi-session consistency. proxy: route traffic through proxy server (format: http://proxy:port). profile: restore previously saved browser state (cookies, localStorage, logged-in sessions). Only one of seed and profile can be specified.'
Document idempotency for state-changing tools. For browser_click: 'Idempotent if the element remains clickable. If the click hides the element or triggers navigation, a retry may fail. Recommended: snapshot before clicking, confirm state after.'
Add rate-limit and timeout guidance to descriptions. 'Each navigation waits for wait_until condition or times out after 30s. If the site is slow, increase timeouts via retry. The server enforces no rate limit between calls, but rapid requests may appear as bot activity to the target site.'