SuperSurf provides a single tool (browser_evaluate) with a reasonable description and basic parameter schema. However, the tool exhibits significant design issues: it violates the single-responsibility principle by combining evaluation, function execution, and expression evaluation; lacks proper parameter descriptions and input validation guidance; provides no documented output schema; and the security model relies on three-layer defense rather than proper privilege gating. The tool name is generic and does not follow verb_object naming conventions (should be something like 'evaluate_javascript' or 'run_javascript'). No other tools (resources, prompts, etc.) are exposed despite the server being a browser automation platform. The codebase shows sophisticated fingerprinting and handle resolution systems in experimental/ modules that are not surfaced as discoverable tools.

• Rename 'browser_evaluate' to 'evaluate_javascript' and refactor to a single clear action: execute JavaScript in page context and return structured result.
• Document output schema explicitly: 'Returns: { result: any, type: string, error?: string, duration_ms: number }' or similar.
• Split 'purpose' parameter into a direct description in the tool description itself (e.g., 'Use this when you need to inspect or manipulate the page directly. For common tasks like clicking, typing, or navigating, prefer dedicated tools.'). Make it non-required or remove it.
• Add mutually-exclusive parameter handling: document that exactly ONE of 'function' or 'expression' should be provided, and return a clear error if both or neither are supplied.
• Expose high-value browser automation tools as separate, well-named tools: navigate_to_url, click_element, type_text, get_element_text, capture_screenshot, query_dom (these exist in experimental/ but are not discoverable).
• Add error handling guidance: 'On SyntaxError, return error with the line number. On timeout, return error suggesting the operation was blocked or page is unresponsive. On security block, return message explaining which pattern was blocked and why.'
• Declare permission scopes (e.g., 'read:page', 'write:page', 'execute:javascript') and document which operations require which scopes.
• Add examples of valid vs invalid inputs in parameter descriptions (but NOT as literal values LLMs might copy, use patterns/constraints instead). E.g., 'function: A JavaScript function body like `return document.title;` (no outer function wrapper needed)'.