Browser Bridge MCP exposes 29 browser automation tools with reasonable naming (verb_noun pattern: list_tabs, close_tab, navigate, click, scrape, etc.). However, descriptions are inconsistent in quality and depth. Many descriptions are terse (10-30 chars) and lack context on WHEN to use the tool or what it returns. Parameter schemas are present and typed, but descriptions for parameters are often minimal. No output schemas are documented. Error handling is absent, tools do not guide recovery or categorize failures. The server is STDIO-only, which is a hard transport limitation. Overall, this is a functional but below-average MCP server that would benefit from richer descriptions, documented output schemas, and error guidance.

• Translate all tool and parameter descriptions to English. Use clear, actionable language: 'List all open browser tabs and return their IDs, titles, and URLs. Use this to discover available tabs before navigating or closing.' (vs. '列出所有标签页').
• Document output schemas for all tools. Example for list_tabs: 'Returns { tabs: [{ id: integer, title: string, url: string }], active_tab_id: integer }'. This enables LLMs to chain tools and extract the right fields.
• Add error handling and recovery guidance. Example for click(): 'If element not found, returns error with message. Try get_a11y_tree() to discover available elements, or use run_script() to verify element exists before clicking.'
• Expand parameter descriptions with valid values, ranges, and examples. Example for 'by' parameter: 'Locator method: css (CSS selector, default), text (visible text match), or xpath (XPath expression). Use css for most cases; use text when element lacks stable selectors; use xpath for complex DOM traversal.'
• Add per-tool usage hints. Example for scrape(): 'Use this to extract structured data from pages without JavaScript evaluation (CSP-safe). Provide item selector (container for each result) and fields mapping (field_name: selector[@attribute]). Returns array of objects with extracted fields.'