Claude-harness provides 9 browser automation tools with basic schemas and descriptions. All tools have input schemas with type definitions and parameter descriptions, meeting minimum requirements. However, descriptions are generic (avg ~40 chars, well below the 194-char baseline for A+ tools), lack actionable context about when to use each tool, and omit error recovery guidance. No output schemas are documented. Tools lack composition hints (e.g., navigate should mention it returns a URL for subsequent clicks). Error handling is minimal, tools return generic error dicts without recovery guidance. Naming is clear (verb_noun pattern) but descriptions fail to distinguish similar tools (click vs type both manipulate elements but lack differentiation). No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the spec.

• Expand tool descriptions to 100-200 chars. For click: 'Click an element matching the CSS selector. Use after screenshot() to identify selectors. Returns success or error if selector not found or timeout exceeded. Retryable on timeout.'
• Document output schemas formally. Add a 'Returns' section to each tool docstring with field names, types, and meanings. E.g., navigate returns {status: string, url: string, title: string, response_status: int|null}.
• Add error recovery guidance. Replace {error: 'Browser not launched'} with {error: 'Browser not launched. Call launch_browser(browser_type="chromium") first.'}. Classify errors as retryable (timeout) vs user-fixable (invalid selector).
• Implement tool annotations in MCP response. Add readOnlyHint: true to navigate, screenshot, get_text, get_attribute, wait_for_selector. Add destructiveHint: true to launch_browser, click, fill, type (they modify browser state).
• Add composition hints in descriptions. E.g., navigate: 'After calling this, use screenshot() to see the page, then click() or fill() to interact.' This guides LLM planning and reduces discovery overhead.