browser-whiskor has 20 tools with basic naming and descriptions, but significant gaps in schema completeness, parameter documentation, and error handling. Most tools have descriptions (10-150 chars, below the 194-char baseline), but many lack detailed parameter descriptions or output schema documentation. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter schemas are present but sparse, many lack type constraints, enums, or validation guidance. Error handling is minimal; no recovery guidance or actionable error messages visible. The server targets browser automation (high-risk domain) but lacks the defensive patterns expected for production agent tools.

• Add tool annotations to all tools: mark read-only tools with readOnlyHint=true, destructive tools (click, navigate, type, exec_module, replay_session) with destructiveHint=true, and idempotent tools with idempotentHint=true. This enables agents to plan safely.
• Expand parameter descriptions for all tools. For 'selector' params, add: 'CSS selector string (e.g., "button.submit", "#main-form"). Must match exactly one element.' For 'tabId', add: 'Numeric browser tab ID from get_tabs().' For 'rect', add: 'Object with x, y, width, height in pixels.'
• Document output schemas for all tools. E.g., screenshot should return {data: string (base64), format: string, width: number, height: number}. get_page_state should return {dom: string, accessibility_tree: string, viewport: object}.
• Add error recovery guidance to high-risk tools. E.g., click: 'If selector not found, call analyze_click() first to verify clickability. If element is hidden, try scrolling with navigate() or get_page_state() to inspect visibility.'
• Implement input validation and sanitization for exec_module. Require explicit allowlist of safe APIs, reject eval/Function constructors, add timeout enforcement, and return clear error messages for blocked code patterns.