No user-submitted related servers found.
Scored across 60 tools
Descriptions do real work disambiguating sibling families (get_slowlog live vs get_slowlog_patterns persisted vs get_cluster_slowlog aggregated; get_latency vs get_latency_history vs get_latency_regressions vs get_inference_latency). But with 60 tools there are many near-duplicates an agent could easily misselect: get_info vs get_health vs get_memory, list_instances vs ai_list_instances vs memory_stores vs cache_list, get_commandlog vs get_commandlog_history vs get_commandlog_patterns. Overlap is manageable only because descriptions explicitly cross-reference each other.
Most names are snake_case verb_noun, but namespacing order is inconsistent: prefix style (cache_list, memory_get, ai_list_instances) mixed with suffix style (list_ai_traces, get_ai_trace, correlate_ai_trace, list_instances). The noun for the same concept also drifts between 'instance' and 'connection' (add_connection/remove_connection vs list_instances/select_instance). Readable, but not a predictable single pattern.
60 tools is far beyond a well-scoped set and forces the agent to choose among many closely related diagnostics (four slowlog tools, four latency tools, multiple discovery tools). The surface could be consolidated substantially (e.g. one slowlog tool parameterized by source/aggregation) without losing capability.
Coverage is genuinely broad for a Valkey/Redis observability server: health, INFO, slowlog/commandlog, latency, clients, cluster, keys/keyslots, ACL audit, caches, agent memory, AI traces, forecasts, and a full propose/approve/reject governance workflow. Minor gaps remain, such as generic key inspection or configuration read/write, but core investigative workflows have no dead ends.