16 tools with explicit registration and Zod schemas. Naming is consistent (chrome_* prefix, verb-noun pattern). Descriptions are present but brief (avg 60 chars, well below 194-char baseline). All tools have input schemas with type constraints. Critical gaps: parameter descriptions are almost entirely missing (LLM cannot infer what tabId, method, params mean beyond the name); output schemas are undocumented (LLMs don't know what fields to expect); error handling is absent from tool definitions. chrome_cdp_send and chrome_evaluate are high-risk tools with minimal guidance on safe usage.

• Add parameter descriptions to all tools. For each parameter, explain: what it controls, valid format/range, and any constraints. E.g., 'tabId (integer, ≥0): The numeric Chrome tab ID to target. Obtain from chrome_user_tabs or chrome_session_tabs.'
• Document output schemas in tool descriptions. Specify the response structure and key fields. E.g., 'Returns {tabs: [{tabId, url, title, active}], count: number}'.
• Expand tool descriptions to 100 - 200 chars. Add context on WHEN to use each tool and how it differs from similar ones. E.g., 'chrome_user_tabs lists all tabs visible to the extension; chrome_session_tabs lists only tabs claimed by this MCP session.'
• Add safety warnings and examples to chrome_cdp_send and chrome_evaluate. Document injection risks, show safe usage patterns, and explain error recovery.
• Constrain chrome_cdp_send's 'method' parameter with an enum of common CDP methods (Runtime.evaluate, Page.navigate, etc.) or document the expected format and provide a discovery tool to list valid methods.