How do I use MCAP MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCAP MCP Server Show me the topics in session_003.mcap" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCAP MCP Server

by turkenberg

Overview Schema Related Servers Score Discussions

Python

Local

MCAP MCP Server

Query your robot's MCAP recordings with SQL — straight from your LLM.

codecov License

Setup

{
  "mcpServers": {
    "mcap-query": {
      "command": "uvx",
      "args": ["mcap-mcp-server[all]"]
    }
  }
}

No install, no database, no API keys. Requires uv.

Related MCP server: MCP Data Analyst

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 — configuration, Docker, development setup, and architecture.

Example SQL (under the hood)

-- 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

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.

Available Tools

6 tools

get_recording_infoA

Get full metadata, channel details, and attachment list for a specific MCAP recording file. Does not require loading. Use this for detailed inspection before loading data.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description carries the full burden. It discloses that the tool returns full metadata, channel details, and attachments, and states it is a read-only operation ('Does not require loading'). This is sufficient for a simple one-parameter tool.

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

Conciseness5/5

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

The description is two sentences with no unnecessary words. It front-loads the purpose and follows with usage guidance, making it efficient and easy to parse.

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

Completeness4/5

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

Given the low complexity (one required parameter, no output schema shown but exists), the description covers what the tool does, what it returns, and when to use it. It misses potential details like error handling or prerequisites, but it is largely complete for the given context.

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 only parameter 'file' has 0% schema coverage. The description clarifies it is 'a specific MCAP recording file' but does not specify format or constraints. It adds some meaning but could be more precise.

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?

The description clearly states the action ('Get') and the resource ('full metadata, channel details, and attachment list for a specific MCAP recording file'). It differentiates from siblings by specifying that it does not require loading, which contrasts with 'load_recording'.

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?

The description provides clear context by stating 'Does not require loading' and 'Use this for detailed inspection before loading data,' implying when to use it (inspection) and when not to (loading). It does not explicitly name alternatives but effectively guides the agent.

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

get_schemaA

Inspect the SQL schema for a recording: topic names, table names, column names and DuckDB types. Does not require loading. Use this to plan SQL queries before running them. Returns a sql_hint with JOIN guidance.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes
`topic`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so the description carries the burden. It states the tool is non-destructive ('Does not require loading') and returns a sql_hint with JOIN guidance. It does not disclose failure modes or exact return format, but is reasonably transparent for a schema inspection tool.

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

Conciseness5/5

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

Three concise, front-loaded sentences with no wasted words. Every sentence adds value: purpose, non-destructive nature, usage guidance, and return value description.

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

Completeness4/5

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

The description covers key aspects: what it does, that it doesn't load, usage, and return. With an output schema present (though not shown), the description does not need to detail return values. Could mention prerequisites (e.g., recording must exist), but overall complete.

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

Parameters2/5

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

Schema description coverage is 0%; the description does not explain the parameters 'file' and 'topic' beyond the tool's general purpose. It mentions 'topic names' but does not clarify how the topic parameter is used. Minimal added value over the schema.

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?

The description clearly states the tool inspects SQL schema for a recording, listing topics, tables, columns, and types. The verb 'Inspect' and specific details distinguish it from sibling tools like load_recording and query.

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?

The description explicitly says 'Use this to plan SQL queries before running them,' giving clear guidance on when to use. It does not provide explicit when-not-to-use or alternatives, but sibling tools provide context.

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

get_versionA

Return the server version, supported encodings, and upgrade command. Use this to check for updates or diagnose compatibility issues.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It indicates the tool returns information but does not disclose any behavioral traits like authentication requirements or rate limits. However, the simplicity of the tool (no parameters, read-only) partially compensates.

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

Conciseness5/5

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

The description is a single sentence that front-loads the output and use case. Every word is valuable and there is no wasted text.

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

Completeness4/5

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

Given the tool has no parameters and an output schema exists, the description sufficiently covers the purpose and usage. It does not elaborate on response structure, but the output schema provides that.

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

Parameters4/5

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

The tool has zero parameters, so baseline is 4. The description adds no parameter-specific information since none exist.

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?

The description clearly states that the tool returns 'the server version, supported encodings, and upgrade command', which is a specific verb and resource. It distinguishes itself from sibling tools like get_recording_info or get_schema by its unique output.

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?

The description explicitly says 'Use this to check for updates or diagnose compatibility issues', providing clear usage context. It does not explicitly mention when not to use it, but the sibling tools cover different use cases.

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

list_recordingsA

Discover available MCAP recording files. Does not require loading. Returns file names, sizes, durations, channel lists, and message counts. Use this first to see what data is available before loading. By default scans the project directory; pass an absolute 'path' to scan any directory on the filesystem.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No
`after`	No
`before`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

States 'Does not require loading,' implying safe, non-destructive operation. With no annotations, this is valuable context. Describes return type (file information) but could mention permissions or scalability (e.g., large directories).

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

Conciseness5/5

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

Three sentences, each serving a purpose: purpose+output, when to use, path parameter detail. No fluff, front-loaded with key information.

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

Completeness3/5

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

Output schema exists but is not shown; description provides a high-level overview and one parameter detail. Missing explanations for two parameters (after, before) that are not in schema descriptions. Adequate for basic understanding but incomplete for full use.

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

Parameters2/5

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

Schema coverage is 0%, so description must compensate. Only 'path' parameter is explained (absolute directory). 'after' and 'before' parameters are not described at all; their purpose and format remain unclear. This is a significant gap.

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?

Description clearly states it discovers MCAP recording files, lists their metadata (names, sizes, durations, etc.), and does not require loading. It distinguishes from sibling tools like load_recording by explicitly noting it's a discovery step.

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 advises to 'Use this first to see what data is available before loading.' Provides context on default project directory scanning and flexibility via absolute path. Lacks explicit exclusions but sufficient for typical use.

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

load_recordingA

Decode an MCAP file and load its data into DuckDB for SQL querying. This decodes all messages and may take seconds to tens of seconds depending on file size. You must call this before running queries. For large files, use 'topics' to load only the topics you need and 'start_time'/'end_time' to narrow the time window — this significantly reduces both load time and memory usage. Set an alias for multi-recording comparison.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes
`alias`	No
`topics`	No
`end_time`	No
`downsample`	No
`start_time`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Describes that decoding all messages may take seconds to tens of seconds, and that filtering reduces load time and memory usage. Since no annotations provided, the description adequately covers behavioral traits.

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?

A single paragraph with clear, front-loaded main purpose. Each sentence adds value, though could be slightly more structured (e.g., bullet points). No wasted words.

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

Completeness4/5

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

Given the tool has 6 parameters and an output schema, the description covers the load process, prerequisites, performance considerations, and usage of optional parameters. Sufficient for a complex tool without needing to explain return values.

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

Parameters4/5

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

With 0% schema coverage, the description explains the purpose of 'file', 'topics', 'start_time', 'end_time', and 'alias', covering most parameters. Only 'downsample' is not described. Adds significant value beyond the schema.

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 specifically that it decodes an MCAP file and loads into DuckDB for SQL querying. Clearly distinguishes from sibling tools like 'query' and 'list_recordings'.

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

Usage Guidelines5/5

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

Explicitly says 'You must call this before running queries' and provides tips for large files (use topics, start_time/end_time to filter) and setting alias for multi-recording comparison, effectively guiding when and how to use.

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

queryA

Execute a SQL query against loaded MCAP data. Supports full DuckDB SQL including JOINs, GROUP BY, window functions, and ASOF JOIN for time-series correlation. Data must be loaded first via load_recording. If a table is missing, call load_recording with the needed topic.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, but the description details supported DuckDB SQL features (JOINs, window functions) and prerequisites. It does not mention error handling or performance impacts, but is fairly transparent.

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

Conciseness5/5

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

Concise at a few sentences with main purpose front-loaded. Every sentence adds value without verbosity.

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?

Given an output schema exists (not needed to explain return values), the description covers prerequisites, capabilities, and usage context thoroughly.

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?

Schema coverage is 0% (no parameter descriptions in schema). The description explains the sql parameter well ('Supports full DuckDB SQL'), but the limit parameter receives no additional explanation beyond its existence.

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?

The description clearly states 'Execute a SQL query against loaded MCAP data', specifying the verb and resource. It distinguishes from siblings like load_recording and list_recordings.

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

Usage Guidelines5/5

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

Explicitly states data must be loaded first via load_recording, and instructs to call load_recording if a table is missing. Provides context on supported SQL features.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

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

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Dataassist-IO
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2
Dot - AI Data Analyst
io.github.zurferr
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Search Databases Data Visualization
2
Contextflo
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1
Vibe BI MCP
ai.vibe-bi
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
Databases Search
2

Related MCP Servers

GraphJinofficial
Databases Search
dosco
A
license
Not graded
quality
A
maintenance
Enables AI assistants to query databases using natural language, with automatic schema discovery and SQL compilation.
Updated 3 days ago (2026-09-01 02:58 UTC)
6,002
3,157
Apache 2.0
MCP Data Analyst
Databases Search
DonMul
A
license
Not graded
quality
D
maintenance
Enables natural language querying of SQL databases using AI, supporting multiple database types and automatic schema discovery.
Updated 7 months ago (2026-02-03 12:00 UTC)
1
MIT
io.github.wenRou21/sqlbot-mcp
Databases Search Data Visualization
wenRou21
A
license
A
quality
B
maintenance
Enables natural-language querying of databases via SQLBot, with datasource discovery, metadata inspection, and report generation.
Updated 2 months ago (2026-06-30 03:41 UTC)
5
MIT
MCP-DB-Server
Databases Search
sujalsamkaria0066
F
license
Not graded
quality
C
maintenance
Enables natural language querying of SQL databases with robust safety guarantees including read-only enforcement, AST validation, and row caps.
Updated 2 months ago (2026-07-07 04:33 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/turkenberg/mcap_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCAP MCP Server

Setup

Usage

Tools

Example SQL (under the hood)

Performance

Update

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GraphJinofficial

Latest Blog Posts

MCP directory API