This server has 17 tools with consistent naming (uia_* prefix) and basic descriptions, but suffers from critical schema and parameter documentation gaps. Most tools lack explicit parameter type definitions in visible code, and descriptions are minimal (10-50 chars, well below the 194-char baseline). The uia_inspect and uia_find tools expose 20+ parameters each with only brief descriptions, violating the pattern:constrained-input and pattern:tool-description rules. No output schemas are documented. Error handling is absent, tools return raw strings with no recovery guidance. The server is read-only (low risk), but parameter validation and LLM-friendly descriptions are severely lacking.

• Add explicit output schemas to every tool. Document the JSON structure returned (e.g., { element: { name, automationId, controlType, ... }, children: [...] }). This enables LLMs to extract and chain results.
• Expand tool descriptions to 100-200 chars. Include WHEN to use each tool and how it differs from similar ones. E.g., 'uia_inspect: Locate a single element by multiple criteria (name, class, automation ID, coordinates). Use when you need detailed properties of one element. Returns element metadata and control patterns.'
• Convert free-form string parameters to enums where values are known. E.g., scope: enum [subtree, descendants, ancestors], cacheView: enum [control, raw], direction: enum [parent, firstChild, lastChild, nextSibling, previousSibling].
• Add parameter constraints in descriptions. E.g., 'x: X screen coordinate (0-65535)', 'timeoutMs: Timeout in milliseconds (100-60000)', 'maxResults: Maximum results to return (1-1000, default 100)'.
• Implement structured error responses. Return JSON with { success: bool, error?: { code, message, recovery_hint } } instead of raw strings. E.g., 'Element not found. Try uia_find() with broader criteria or uia_desktop() to explore the tree.'