Server has 27 tools with consistent naming (verb_noun pattern) and complete input schemas. All tools have descriptions and parameters are typed. However, descriptions are minimal (10-50 chars, well below the 194-char baseline), lack context on WHEN to use tools, and omit error recovery guidance. Output schemas are undocumented, LLMs cannot predict return structure. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification. Error handling returns generic strings rather than actionable recovery steps. Composition is sound (single responsibility per tool), but descriptions need expansion to meet production standards.

• Expand all descriptions to 100-200 chars. Include WHEN to use the tool, dependencies, and expected output. Example: 'Take a screenshot of the entire screen. Use this to see the current desktop state before interacting with windows. Returns a file path or base64-encoded PNG depending on the format parameter.'
• Document output schemas for all tools. For list_windows, specify: 'Returns JSON array of objects with fields: id (integer), title (string), wmClass (string), position (object with x, y), size (object with width, height), state (string), workspace (integer).'
• Add tool annotations to the schema. Mark read-only tools with readOnlyHint=true, destructive tools with destructiveHint=true, and idempotent tools with idempotentHint=true. This enables LLMs to reason about safety and retry logic.
• Enhance error messages with recovery guidance. Instead of 'Error: Window not found', return 'Window not found. Call list_windows() to see available windows, or check the window_id parameter.'
• Add confirmation support for destructive tools. Implement a dry_run parameter for close_window and cleanup_screenshots, or add a separate confirm_close_window tool that requires explicit confirmation before executing.