Skip to main content
Glama

convert_dataset

Transform embodied-AI datasets between JSONL and LeRobot v2.1 layouts, handling numeric features while reporting camera streams without re-encoding.

Instructions

Convert a dataset to another layout: 'jsonl' (canonical, dependency-free) or 'lerobot' (v2.1 parquet, needs pyarrow). Numeric features only; camera streams are reported, not re-encoded.

Input Schema

NameRequiredDescriptionDefault
sourceYes
targetNojsonl
episodesNo
overwriteNo
destinationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose real behavioral facts — the pyarrow dependency for lerobot and that camera streams are reported rather than re-encoded. But it says nothing about the destructive/side-effecting nature of writing to destination, what `overwrite` does when false, or what the call returns.

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?

Two dense sentences, zero filler, with the format choice and its constraints front-loaded. Every clause (dependency requirements, numeric-only restriction, camera handling) adds information an agent needs.

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?

For a five-parameter mutation tool with no annotations and no output schema, the description covers format semantics and data-type scope well but leaves the episode-subset selector, overwrite behavior, and result expectations unexplained. It is adequate but noticeably incomplete.

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 the description must explain all five parameters. It does a good job on `target`, giving meaning and requirements for both enum values, but `source`, `destination`, `episodes`, and `overwrite` are entirely undocumented — most of the schema remains opaque.

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

Purpose4/5

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

States a concrete verb (convert) and resource (dataset) plus the exact target layouts, which clearly separates it from siblings like validate_dataset, summarize_dataset, or detect_dataset. It doesn't explicitly name a sibling or competing operation, so it falls just short of a 5.

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

Usage Guidelines3/5

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

The description helps choose the target format by giving requirements ('jsonl' is dependency-free, 'lerobot' needs pyarrow), which is useful in-tool guidance. However, it never says when to convert at all, when to prefer other siblings (e.g., detect_dataset first), or what preconditions the source must satisfy.

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