Related Servers

Two parallel semantic pipelines cover the same Chrome automation ground: ax_read/ax_activate with target=paired_page versus chrome_read/chrome_activate, with no clear rule for when to pick which. Clicking a UI element can also be done through ax_activate, chrome_activate, click_mark, or left_click, and legacy ax_click/ax_focus/ax_set_value plus the read_ui alias add further alternatives. Descriptions label preferred vs legacy vs compatibility routes, but the boundaries remain blurry enough to invite misselection.

There is a common verb_noun pattern in tools like read_clipboard, write_clipboard, click_mark, open_application, type_text, zoom_region, and inspect_app, and the ax_ and chrome_ families are internally consistent. However, many tools break that pattern: action-only names (scroll, wait, screenshot, ocr), noun_noun names (cursor_position, batch_actions, key_combo), and adjective_noun names (left_click, right_click, double_click). The set is readable but lacks one predictable convention.

At 35 tools, the server exceeds the well-scoped 3-15 range and sits in the too-many category. Several tools are explicitly legacy, compatibility, or debug variants (ax_click, ax_focus, ax_set_value, read_ui, click_mark, dump_ax), and the ax_* versus chrome_* Chrome pipelines duplicate capability rather than each earning a distinct place. The broad computer-use domain justifies a rich surface, but this set could be consolidated.

Coverage is strong across the apparent domain: native UI read/action, Chrome semantic lifecycle (pair, status, read, activate, focus, set value, scroll, release), visual fallbacks (screenshot, OCR, zoom), low-level input (mouse, keyboard, clipboard, scroll), and application/window discovery. Gaps such as drag-and-drop, hover, window manipulation, and conditional waits are real but minor and usually workable through existing primitives.