Server has 7 tools with complete JSON Schema definitions and descriptions in Japanese. However, descriptions are minimal (avg ~80 chars, well below the 194-char baseline), lack WHEN/WHY context, and omit error recovery guidance. Parameter descriptions exist but are sparse. No output schemas documented. Missing tool annotations (readOnlyHint/destructiveHint). Naming is verb-based but generic (act_on_element, manage_session). No pagination support visible. Error handling is absent, tools return raw failures with no recovery guidance.

• Expand tool descriptions to 150 - 250 chars. Include WHAT (e.g., 'Opens a URL in a browser'), WHEN (e.g., 'Call this first to load a page'), and WHAT IT RETURNS (e.g., 'Returns a page_id for use in subsequent calls'). Example: 'open_page: Opens a URL in a browser and returns a page_id. Call this first to load a page. Supports wait_until options (load, domcontentloaded, networkidle) to control when the tool returns.'
• Document output schemas for all tools. For observe_page, document that it returns {page_id, title, url, status, headings[], interactive_elements[], forms[], text_summary}. For extract_structured_data, document the structure of extracted data. This enables LLMs to plan multi-step workflows.
• Add error handling guidance to tool descriptions. E.g., fill_form: 'If submission fails, call diagnose_failure to analyze the page state and identify the issue (missing fields, validation errors, etc.).'
• Add tool annotations via inputSchema metadata or description hints. Mark observe_page and extract_structured_data as readOnly. Mark act_on_element, fill_form, manage_session as destructive/write operations. This helps LLMs reason about side effects.
• Rename act_on_element to click_element or interact_with_element to clarify intent. If the tool supports multiple actions (click, hover, focus), document when each is appropriate in the description.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry