Skip to main content
Glama

analyze_bag

Summarize a ROS 2 bag at a given path, returning storage format, duration, per-topic message rates, counts, and detected anomalies for debugging.

Instructions

Summarize a ROS 2 bag at path. Returns a BagAnalysis with storage format, duration, message count, per-topic stats, detected anomalies and mode_effective (live or mock). Per topic, frequency_hz is (n - 1) / (last - first message time) of that topic (frequency_basis topic_span), with first_timestamp_ns, last_timestamp_ns and latched; a latched topic whose messages all fall within 1 second (e.g. /tf_static, a start-up burst) has a null frequency_hz, while a latched topic published over a longer span keeps its rate. When the bag cannot be read locally, or is a large .mcap (over 200 MiB), the rate falls back to count / bag duration (bag_duration) and note says why. Live mode runs ros2 bag info and accepts .mcap and .db3 files plus rosbag2_* directories (ROS 1 .bag files are not readable by ros2 bag info; use peek_bag_samples for those); mock mode returns fixture data for any path suffix except clearly non-bag ones. Raises an MCP error if the path is malformed, missing in live mode, or unparseable, or if no ros2 CLI is available. Anomaly detection is available in mock mode only. Read-only; no side effects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to a bag: a file ending in `.mcap` or `.db3`, or a `rosbag2_*` directory. `peek_bag_samples` also reads ROS 1 `.bag` files; `analyze_bag` does not (`ros2 bag info` cannot open them). Leading/trailing whitespace is stripped. Null bytes and otherwise malformed filesystem paths are rejected. Existence and bag format are validated by the live adapter (mock mode accepts any well-formed path).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoWhy the result is less detailed than usual, for example per-topic rates computed over the whole bag duration because the bag was too large to read per-topic message times. `None` when there is nothing to add.
pathYesPath to the analyzed bag, as supplied by the caller. May point to a file (`.mcap`, `.db3`, or ROS 1 `.bag` for `peek_bag_samples`) or to a `rosbag2_*` directory.
topicsYesPer-topic statistics for every topic present in the bag.
anomaliesNoHuman-readable notes about gaps, clock jumps, or other oddities. Populated in mock mode only; live mode does not detect anomalies.
bag_formatNoConcrete bag container format detected by the reader: `mcap` (Foxglove MCAP), `db3` (ROS2 rosbag2 SQLite), `bag` (ROS1 legacy chunked), or `unknown` when the reader could not classify. `None` when the bag was summarized from `ros2 bag info` text, which carries no format information.
message_countYesTotal number of messages across all recorded topics.
mode_effectiveYesRuntime mode the adapter served this response in: `live` (real ROS2 introspection) or `mock` (deterministic fixtures). Lets a caller tell a real graph from a demo one without calling `health_check`.
storage_formatNo`mcap`, `sqlite3`, or other storage identifier when known.
duration_secondsYesTotal bag duration, in seconds (wall clock between first and last message).
participants_recordedNoDDS participants recorded in the bag when the container format embeds participant metadata. MCAP can carry it via channel metadata records; ROS2 `.db3` and ROS1 `.bag` generally do not. Empty list when not available, which is the common case.
recording_duration_nsNoRecording duration in nanoseconds when readable from the bag's index. `None` when only `ros2 bag info` text was parsed; `duration_seconds` (float) is the always-populated fallback that downstream LLM consumers should prefer when this is `None`.
samples_decoded_countNoTotal decoded sample count across all topics produced by the bag reader. `0` when the reader only parsed metadata or when `rosbags` is not installed on the host. Use `peek_bag_samples` to pull the actual sample payloads for a specific topic.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.6

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it declares read-only/no side effects, enumerates the exact MCP error conditions (malformed path, missing in live mode, unparseable, no ros2 CLI), documents the large-.mcap fallback with a `note` field, and discloses that anomaly detection exists only in mock mode.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then layered detail; nearly every sentence carries distinct behavioral information (latched-topic rate rule, fallback, error list). It is dense to the point of being heavy, and the bolded mode blocks add visual weight without new semantics, so a 4 rather than 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with fallback paths, two execution modes, and error conditions, this is complete: return shape is named, edge cases (latched topics, oversized .mcap, unreadable bags) are handled, and an output schema exists so deeper return-value detail is unnecessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single `path` parameter already has 100% schema description coverage covering accepted suffixes, whitespace stripping, and live-vs-mock validation. The description restates the format rules and the ROS 1 exclusion but adds little path syntax that the schema does not already carry, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Summarize a ROS 2 bag at path') and names the concrete artifact returned (a BagAnalysis with storage format, duration, per-topic stats). It also differentiates itself from the sibling peek_bag_samples by noting that ROS 1 .bag files must go there instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the ROS 1 .bag case to peek_bag_samples and explains when the live adapter falls back to count/bag-duration. It does not explain how live vs mock mode is selected (no mode parameter exists), which leaves a small inference gap, so not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.