MCAP MCP Server
by turkenberg
README.md
# MCAP MCP Server
**Query your robot's [MCAP](https://mcap.dev) recordings with SQL — straight from your LLM.**
[](https://codecov.io/gh/turkenberg/mcap_mcp_server)
[](https://github.com/turkenberg/mcap_mcp_server/blob/master/LICENSE)
## Setup
```json
{
"mcpServers": {
"mcap-query": {
"command": "uvx",
"args": ["mcap-mcp-server[all]"]
}
}
}
```
No install, no database, no API keys. Requires [uv](https://docs.astral.sh/uv/getting-started/installation/).
## Usage
Just talk to your LLM:
- *"Tell me what topics are in session_003.mcap"*
- *"In session_017.mcap find all moments where voltage dropped below 22V"*
- *"Correlate IMU acceleration with motor current."*
- *"Compare average battery voltage across my last 5 runs"*
- *"What version of mcap-mcp-server am I running? Update it"*
## Tools
| Tool | Needs loading | What it does |
|------|:---:|-------------|
| `list_recordings` | no | Find MCAP files in your project (or any path) |
| `get_recording_info` | no | Metadata, channels, attachments for a file |
| `get_schema` | no | SQL table names & column types — for query planning |
| `load_recording` | — | **Decode MCAP into DuckDB** (the LLM calls this automatically) |
| `query` | yes | Run SQL (full DuckDB — including ASOF JOIN) |
| `get_version` | no | Server version, available decoders, upgrade command |
**[Project documentation](https://turkenberg.github.io/mcap_mcp_server/index.html)** — configuration, Docker, development setup, and architecture.
## Example SQL (under the hood)
```sql
-- Time-windowed stats
SELECT (timestamp_us / 1000000) as second,
AVG(voltage) as avg_v, MIN(voltage) as min_v
FROM battery GROUP BY second ORDER BY second
-- Cross-sensor correlation via ASOF JOIN
SELECT b.timestamp_us, b.voltage, i.linear_acceleration_x
FROM battery b ASOF JOIN imu i ON b.timestamp_us >= i.timestamp_us
-- Multi-recording comparison
SELECT 'run1' as run, AVG(voltage) FROM r1_battery
UNION ALL
SELECT 'run2', AVG(voltage) FROM r2_battery
```
## Performance
Metadata tools (`list_recordings`, `get_recording_info`, `get_schema`) return in **< 1 ms** regardless of file size. SQL queries execute in **1–20 ms** once data is loaded. The one-time `load_recording` cost scales with file size:
| Messages | File size | Load time | Memory | Query time |
|----------|-----------|-----------|--------|------------|
| 1K | 23 KB | 8 ms | < 1 MB | 1 ms |
| 10K | 220 KB | 90 ms | 0.5 MB | 1–3 ms |
| 100K | 2.2 MB | 0.7 s | 5 MB | 1–5 ms |
| 500K | 11 MB | 3.9 s | 23 MB | 2–9 ms |
| 1M | 23 MB | 8 s | 46 MB | 2–13 ms |
| 2M | 48 MB | 18 s | 92 MB | 2–22 ms |
*Measured on Apple M4 with JSON-encoded messages, 5 fields per message. Query times are median across aggregation, filter, and window function queries. Memory is the DuckDB in-memory footprint (default budget: 2 GB).*
> **Tip:** use `topics` and `start_time`/`end_time` filters on `load_recording` to load only what you need.
## Update
```bash
uvx mcap-mcp-server[all] --upgrade
```
Or ask your LLM — the `get_version` tool returns the running version and the upgrade command.
## License
GNU General Public License v3.0 — see [LICENSE](LICENSE).
TDQS
A4.4/5.0
Scored across 6 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: listing, inspecting, schema inspection, version info, loading, and querying. There is no ambiguity or overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_recordings, load_recording). Even 'query' fits as a single verb without a noun, maintaining uniformity.
Tool Count5/5
With 6 tools, the server is well-scoped for its domain of MCAP recording management. Each tool serves a necessary step in the workflow without redundancy.
Completeness5/5
The tool surface covers the full lifecycle: discovery, inspection, loading, and querying. No obvious gaps exist for typical usage scenarios.
Maintenance
ActivityInactive
ResponsivenessNo issues