Bagel

View saved version →

---
name: authoring-pipelines
description: Use when the user wants a bagel data pipeline — reducing a log to windows around events ("keep 30s around every hard brake"), recurring snippets/GIFs/exports, or any tasks-and-gates automation over robot data.
---

# Authoring bagel pipelines

The bagel MCP server owns the authoring workflow, including the
reduce-vs-snippet decision, window/debounce extraction, and the
preview-before-run rule. Do not write pipeline YAML from memory:

1. Call `run_poml_capability` with `poml_path="./src/agent/compose/pipeline.poml"`.
2. Follow it exactly. In particular: always call `preview_pipeline` and show the
   user the summary (events found, data kept) BEFORE running anything.
3. Use `list_pipeline_capabilities` for the exact task/gate module paths and
   arguments — never guess them.
4. Execute the approved config through the MCP tools (`run_pipeline`, or
   `run_pipeline_batch` for many sources). The capability also mentions a host
   CLI (`run.py`); that path is for users at a terminal in the repo, not for
   plugin sessions — do not shell out to it.

If the connection fails, the server container is not running — see
references/formats.md.

View saved version →

---
name: exporting-visualizations
description: Use when the user wants to SEE robot data — visualize, plot, replay, or export a log or query result from bagel to a viewer or training format (Rerun, Lichtblick, PlotJuggler, LeRobot).
---

# Exporting visualizations

Pick the target by what the user is doing, then call the matching bagel export
tool:

| User goal | Target | Why first choice |
|---|---|---|
| Explore/replay multimodal data (3D, images, series) | Rerun (`export_for_rerun`) | Best open-source robotics viewer |
| Web-based bag review, Foxglove-style | Lichtblick (`export_for_lichtblick`) | Open-source; preferred over Foxglove |
| Plot signals from an artifact on the desktop | PlotJuggler (`export_for_plotjuggler`) | Artifacts land on the host for it |
| Build a training dataset | LeRobot (`export_for_lerobot`) | Direct dataset export |

Camera-topic GIFs for quick evidence come from the triage/pipeline workflows,
not an export tool. Export artifacts land under the artifacts directory on the
host — always report the output path.

View saved version →

---
name: operating-live-sinks
description: Use when subscribing to live robot data (MQTT, rosbridge) through bagel, managing standing pipelines that survive restarts, or when questions about live-buffer sizes and disk usage come up.
---

# Operating live sinks

Live data flows into per-topic rolling disk buffers on the bagel server;
standing pipelines run against them.

- Discover what a live source publishes with `list_live_topics`, then
  `subscribe_live_topics` to start recording; each topic gets a rolling buffer
  (`JSONL_BUFFER_SIZE_PER_TOPIC_BYTES`, default 1 GB per topic).
- The subscription's directory path is returned; pass it as the `path` for
  queries and pipelines over the live data.
- Standing pipelines that must survive container restarts belong in the
  `STARTUP_PIPELINES_FILE` manifest: they are re-established on boot.
- Artifacts (snippets, exports) land under the artifacts directory and are
  never cleaned up automatically: they are the user's deliverables. See
  references/settings-knobs.md for every knob and its default.

View saved version →

---
name: triaging-robot-logs
description: Use when investigating a robot log or flight log with bagel — finding events, anomalies, or "what happened around X" in rosbags, MCAP, CAN, MDF4, ULog, or Betaflight files. Routes to the server's triage capability.
---

# Triaging robot logs

The bagel MCP server ships its own step-by-step triage workflow. Do not
improvise one: fetch and follow it.

1. Call `run_poml_capability` with `poml_path="./src/agent/triage/investigate.poml"`.
2. Follow the returned instructions exactly (describe-first, windowed queries,
   snippet/GIF evidence).

If the bagel tools are missing or the connection fails, the server is probably
not running — the user must start the Docker container for their data format
first (see references/formats.md for the format → image → extra-args table,
including the CAN `dbc` requirement).