Yurei provides 13 browser automation tools with explicit schemas and descriptions. However, most descriptions are terse (10-40 chars), parameter descriptions lack detail on constraints/formats, and output schemas are not documented. Tools like 'computer' combine multiple actions (click, type, scroll, screenshot) into one, violating single-responsibility. No error recovery guidance. Naming is verb-forward but some tools are overloaded (e.g., 'computer' with 10+ action types). Schema definitions are present but minimal, most parameters lack format/range constraints. This is typical of community automation servers: functional but not LLM-optimized.

• Expand tool descriptions to 50-200 chars. Example: 'Get context about open tabs' → 'Retrieve metadata (title, URL, active state) for one or all open tabs. Use this to discover available tabs before navigating or reading page content.'
• Split 'computer' tool into separate, single-purpose tools: take_screenshot, click_element, type_text, scroll_page, hover_element, press_key, drag_element, wait_for_condition. This enables agents to compose actions without guessing which 'action' enum value to pass.
• Document output schemas for all tools. Add a 'Returns' section to each description listing field names, types, and meanings. E.g., read_page returns {elements: [{ref, tag, role, text, ...}], screenshot?: string}.
• Add enum constraints and format hints to parameters. E.g., action: enum[screenshot|left_click|right_click|...], coordinate: [number, number] with description 'Pixel coordinates relative to viewport (0,0 = top-left)', tabId: number with description 'Tab ID from tabs_context; omit for active tab'.
• Add error recovery guidance to tool descriptions. E.g., navigate: 'If URL is invalid, returns error with suggestion to check protocol (http/https). If tab is closed, returns error suggesting tabs_create to open a new tab.'