No user-submitted related servers found.
Scored across 135 tools
Multiple tool clusters have unclear boundaries: stop_debug vs terminate_debug, evaluate_expression vs quick_evaluate, get_exception_info vs get_exception_context, and get_trace_log vs get_trace_delta all overlap in purpose. The terse ui_* evidence tools (ui_text, ui_property, ui_query, ui_focus, ui_grid, ui_snapshot, ui_diff) plus the monitor family (ui_events, ui_monitor_start/wait/events/poll) and four key-sending tools (ui_send_keys, ui_send_keys_focused, ui_send_keys_batch, ui_key_sequence) create significant misselection risk despite thorough descriptions.
The core debugger tools follow a clean verb_noun snake_case pattern (get_call_stack, add_breakpoint, continue_execution). However, the ui_* family mixes verb_noun names with bare nouns (ui_text, ui_property, ui_grid, ui_query, ui_snapshot, ui_diff), and run_runtime_smoke inverts the established runtime_smoke_* prefix convention. The naming style is mostly readable but the pattern is unpredictable across families.
135 tools is an extreme count for any MCP server, far exceeding the 50+ threshold. Even accounting for three subdomains (debugging, UI automation, smoke testing), each area carries heavy redundancy with dozens of near-variant tools per concern. This volume will overwhelm agents and dilute tool selection quality.
The debugger surface is remarkably complete: session lifecycle, breakpoints, stepping, variables, memory access, output capture, source search, symbols, Edit-and-Continue, and exception handling are all covered, with extensive UI automation and smoke-test workflows on top. Minor gaps include no attachable-process enumeration, no persistent watch-expression list, and single-session-only management.
