No user-submitted related servers found.
Scored across 19 tools
Most tools have clearly distinct purposes (list_windows vs find_window vs get_window_rect each serve different needs), and the description-heavy element discovery trio (element_at_point, skyshot, find_elements) is distinguished by use case. The main ambiguity is element_action vs element_action_at — the same action vocabulary addressed by different handles — and the three 'reach an element' paths could cause misselection, though the descriptions mitigate this.
Action tools follow a solid verb_noun pattern (list_windows, capture_window, send_keys, open_application), but several query/diagnostic tools break it by dropping the verb: cursor_position, skyshot, coexistence_status, and element_at_point are noun phrases or brand names. The uniform tool_ prefix and readable names keep it navigable, but the mixed convention is noticeable.
At 19 tools this sits in the heavy range, and the count is inflated by redundant addressing paths (element_action vs element_action_at, and three separate element-discovery tools). However, the server genuinely spans several sub-domains — window management, element access, input injection, clipboard, display enumeration, and coexistence policy — so the breadth is defensible.
The surface covers the full automation loop well: discover (find_window, find_elements, element_at_point, skyshot), read (read_element, capture_window, clipboard_read), and act (click_at, type_text, send_keys, element_action, element_action_at, open_application). Notable gaps are window manipulation (no close/resize/move/activate tool — only geometry reads) and no drag/gesture operation, but agents can work around these.