Missy exposes 20 tools with consistent naming (verb_noun pattern) and complete input schemas. However, descriptions are terse (avg ~60 chars, well below the 194-char baseline), parameter descriptions are sparse or missing, and output schemas are entirely undocumented. Error handling guidance is absent. Tools are well-scoped (single responsibility), but lack the LLM-optimization depth expected of production systems. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification in the source.

• Document output schema for every tool. Example: 'Returns {success: bool, element_id: string, text: string}' for atspi_get_text. This enables LLMs to chain calls and extract required fields.
• Expand tool descriptions to 100 - 200 chars. Include WHEN to use (e.g., 'Use atspi_click for GTK/X11 apps; use browser_click for web pages') and WHAT happens on failure (e.g., 'Returns error if element not found; try desktop_status first to verify accessibility is available').
• Add parameter descriptions for all inputs. For 'element_name', clarify: 'The accessible name or role of the element (e.g., "OK button", "text input"). Use atspi_get_tree to discover available elements.'
• Add tool annotations to schema. Mark read-only tools with readOnlyHint: true (atspi_get_tree, browser_screenshot, graph_query); mark destructive tools with destructiveHint: true (install_software_confirmed, browser_close); mark idempotent tools with idempotentHint: true where applicable.
• Document error cases and recovery paths. Example for browser_wait: 'Timeout error if selector not found within timeout_ms. Verify selector with browser_screenshot first, or use browser_get_content to inspect page structure.'