No user-submitted related servers found.
Scored across 18 tools
The set splits cleanly along layers (ROS 2 graph vs raw DDS vs bag files) and each tool's description explicitly cross-references the sibling to use instead, e.g. list_nodes vs list_participants vs list_endpoints, and sample_messages vs peek_dds_samples vs peek_bag_samples. Residual overlap remains: get_topic_info's QoS and list_endpoints' qos both describe reliability/durability, diagnose partially duplicates health_check plus every list call, and topic_metrics vs sample_messages' `rate` both report frequency. Boundaries are nonetheless statable, so misselection risk is low but not zero.
All names are snake_case and most follow verb_noun (list_nodes, get_topic_info, detect_qos_mismatches, peek_bag_samples, analyze_bag). A minority break the verb pattern with noun-only or bare-verb names (graph_diff, participant_events, topic_metrics, health_check, diagnose), but these are still readable and semantically clear. Minor deviation, not a mixed convention problem.
18 tools is at the upper edge but each covers a distinct source/format combination (ROS graph, DDS bus, MCAP/db3/ROS1 bags) plus one aggregate `diagnose`, so few feel redundant. The triplication of sampling tools across sources and the separate list/get pairs for nodes, topics, participants and endpoints inflate the count slightly beyond what the purpose strictly requires.
For a deliberately read-only observability server, coverage is strong: discovery for nodes/topics/participants/endpoints, QoS mismatch diagnosis, live and offline sampling, temporal metrics, TF tree, graph diffing, health and an aggregate diagnose. Gaps: services and actions have no first-class listing or inspection tool (only an `include_internal` flag on list_endpoints), and there is no dedicated log query beyond /rosout filtering inside sample_messages or diagnose's log group.