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 the key behavior that the operation is an upsert and that unchanged datasets are skipped. However, it never says what upsert overwrites in existing catalog rows, whether the operation is reversible, how errors on unreadable datasets are handled, or how expensive a large tree scan is.

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

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

Two short sentences, front-loaded with the primary action and immediately followed by the one behavioral caveat that matters most. No filler or restated title.

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

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

For a 5-parameter mutating tool with no annotations, no output schema, and 40% schema coverage, the description leaves significant gaps: return value, force/max_depth semantics, overwrite scope, and failure behavior are all unaddressed.

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

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

Schema description coverage is only 40% (only db and validate are documented), and the description adds nothing about root, max_depth, or force — 'force' in particular is left for the agent to guess as the override for the incremental skip. Besides a weak hint at the skip behavior, no parameter meaning is clarified beyond the schema.

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

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

States a concrete verb chain (scan, load, upsert) against a specific resource (directory tree → SQLite catalog), which clearly separates it from read-only siblings like catalog_search and catalog_stats. It never names those siblings explicitly, so differentiation is inferred rather than stated.

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

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

'Incremental: unchanged datasets are skipped' implies the tool's role for repeat runs, but there is no explicit when-to-use/when-not guidance and no mention of the natural follow-up tools (catalog_search, catalog_stats, quality_report). An agent must infer the workflow placement.

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

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

No annotations exist, so the description carries full behavioral burden. It says nothing about read-only semantics, pagination behavior of 'limit', default ordering, result size, or what a result entry contains — only the filter dimensions.

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

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

One sentence, front-loaded with the verb and resource, zero filler. Every listed item maps to a real parameter and earns its place.

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

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

An eight-parameter search tool with no annotations, no output schema, and no schema descriptions needs more than a one-line field list. The required 'db' scope, 'limit' pagination semantics, and the shape of returned catalog entries are all undocumented.

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

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

Schema coverage is 0%, so the description must compensate: it names six of the eight parameters (text, format, robot_type, min_episodes, min_duration, min_score). However, it omits the required 'db' parameter and 'limit' entirely, and phrases the numeric filters as bare nouns ('episode count', 'duration') leaving ambiguous whether they are minimum thresholds.

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

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

States a specific verb and resource ('Query the dataset catalog') and enumerates the filter dimensions it accepts, so the agent knows this is the search/filter entry point. It does not distinguish itself from siblings like catalog_index, catalog_stats, or list_formats, which are the likeliest confusion points.

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

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

No when-to-use, when-not-to-use, or alternative is given. An agent must infer from the name alone whether this or catalog_index / catalog_stats is correct for listing datasets, and there is no mention of prerequisites such as which 'db' to target.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the return metrics, which is useful since there is no output schema, but it does not explicitly state that this is a read-only aggregation, what the required database parameter represents, or any access constraints.

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

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

The description is a single front-loaded sentence that enumerates the returned totals without waste. Every phrase contributes to understanding what the tool reports.

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

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

For a simple aggregation tool with no output schema and no annotations, the description adequately lists the return metrics. However, it leaves the required parameter undocumented and provides no usage guidance, so it is only partially complete for correct invocation.

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

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

The single required parameter 'db' has 0% schema description coverage, and the description never mentions or explains it. The description does not compensate for the schema gap by clarifying whether 'db' is a database name, catalog identifier, or path.

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

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

The description clearly states that this tool returns aggregate catalog totals, enumerating the specific metrics: datasets per format, episodes, frames, duration, robot types, and last index time. It is distinguishable from list-oriented siblings like catalog_search or list_formats, though it does not explicitly name those alternatives.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as catalog_index, catalog_search, or list_formats. Usage is only implied by the mention of totals, and there are no exclusions or prerequisites.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden. It does add one valuable behavioral fact beyond the schema — the result includes confidence and evidence, not just a bare format label — and "on-disk" implies a read-only inspection. However, it says nothing about failure behavior for unrecognized formats, whether the whole tree is scanned (cost/latency on large datasets), or whether a path must exist locally.

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

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

One front-loaded sentence with zero filler; the format enumeration and the confidence/evidence clause each carry information an agent needs.

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

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

For a one-parameter detection tool with no output schema, the description is nearly sufficient: it names inputs, candidate outputs, and that results come with confidence and evidence. The remaining gap is the unrecognized-format/failure path, which an agent would want before calling it on arbitrary paths.

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

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

Single parameter at 100% schema description coverage ("File or directory to inspect"), so the schema already does the work and baseline 3 applies. The description adds no path semantics such as local-vs-remote, symlink handling, or depth of inspection.

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

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

Specific verb ("Identify") plus resource ("on-disk format of an embodied-AI dataset"), with the candidate formats enumerated so an agent knows exactly what output to expect. It is distinguishable from validate_dataset/convert_dataset/summarize_dataset by the format-identification framing, but it never explicitly contrasts with list_formats, which is the nearest ambiguous sibling.

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

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

Usage is only implied: an agent can infer this is the pre-flight step when the format of a given path is unknown. There is no explicit when/when-not, no mention of ordering relative to validate_dataset or convert_dataset, and no disambiguation from list_formats (supported formats) or catalog_search.

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

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

No annotations are provided, so the description carries the full burden. It discloses the manifest's content shape, which is genuinely useful, but says nothing about whether a file is written, where, whether it overwrites existing output, or whether the operation is read-only or mutating.

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

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

A single front-loaded sentence: the action first, then the manifest's structure, then the consumer. Every clause adds information and nothing is padded.

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

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

With five parameters, 20% schema coverage, no annotations, and no output schema, the description leaves too much unsaid — notably what 'z', 'max_tasks', and 'include_segments' control and whether a file is produced at 'out'. Adequate for understanding the artifact, inadequate for calling it correctly.

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

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

Schema description coverage is only 20%, so the description must compensate, and it does not: 'path', 'z', 'max_tasks', and 'include_segments' are never mentioned. Only 'out' has a schema description, so most parameters are opaque.

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

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

States a concrete verb and artifact ('Generate an annotation manifest') and even previews what each task contains (episode, frame range, cues, question). That is far more specific than any sibling in the list, though it never explicitly contrasts itself with tools like segment_episodes or plan_windows.

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

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

The phrase 'ready for a human reviewer or a vision-language model' hints at the downstream consumer but gives no when-to-use condition, no prerequisites (e.g. must the dataset be detected/segmented first?), and no alternatives. An agent must infer placement in the pipeline.

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

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

There are no annotations, so the description carries the burden, but it discloses the content of the response (formats, detection, dependency, checks), which implicitly signals a safe read-only reference call. It does not state whether output is static/cached or how large the list may be.

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

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

A single front-loaded sentence with no filler; every clause adds a distinct fact about what is returned.

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

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

With no parameters, no annotations, and no output schema, the description is the only carrier of semantics, and it fully enumerates the fields an agent will get back. Nothing needed to invoke or interpret the call is missing.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no input is needed.

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

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

The description pairs a specific verb ("List") with a specific resource ("supported dataset formats") and enumerates exactly what each entry covers: detection method, optional dependency, and validation checks. That content makes it clearly distinct from action-oriented siblings like detect_dataset, validate_dataset, or convert_dataset.

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

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

Usage is only implied: an agent can infer this is the reference lookup to consult before calling detect_dataset or validate_dataset, but the description never says when to use it or what it is not for. No alternatives are named.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not say whether planning writes files or only computes a result, what the return value looks like, or whether any permissions or side effects are involved.

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

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

The description is a single sentence with no wasted wording, and the core purpose is front-loaded. The parenthetical is somewhat cryptic but does not make the sentence bloated.

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

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

With four parameters, no annotations, no output schema, and 0% schema description coverage, the definition is too thin. It omits key details about the input parameters, the expected output plan, and how this differs from related tools like segment_episodes.

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

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

Schema description coverage is 0%, so the description should compensate, but it only vaguely names window and stride and mentions episode/start/end, which do not correspond to the actual schema parameters. It leaves path and limit entirely unexplained and gives no units, defaults, or constraints for the parameters it does mention.

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

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

The description gives a specific verb ('Plan') and resource ('fixed-length training windows over the episodes of a dataset'), which is enough to understand the core operation. It does not, however, distinguish this from the sibling tool segment_episodes, which likely has overlapping territory.

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

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

There is no explicit guidance on when to use plan_windows versus segment_episodes or any other sibling. The only implied usage is planning windows, but no exclusions or routing conditions are stated.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the analysis method ('robust z-scoring') and the anomaly classes detected, which is real added context, but it never says whether the tool is read-only, whether it writes a report to disk, or whether results are returned inline, which matters for a tool that may be run against large datasets.

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

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

A single dense sentence that front-loads the two main capabilities and contains no filler. Every clause (the statistic list, the anomaly types, the z-scoring method) contributes distinct information.

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

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

For a six-parameter, mutation-status-unknown tool with no annotations, no output schema, and zero parameter documentation, the description leaves too much open. It does not say what the return value looks like (statistics table? anomaly list?) or how the boolean flags change output, which the agent needs in order to call it correctly.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate and largely does not. 'Robust z-scoring' hints at the meaning of the z threshold parameter, but features, episodes, skip_anomalies, include_segments, and the required path are entirely unexplained, so an agent cannot infer what skip_anomalies does versus simply reading the anomaly output.

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

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

The description names two specific operations ('compute per-feature statistics' and 'detect anomalous windows') with concrete outputs (range, mean, std, percentiles, NaN ratio; jumps, stalls, non-finite spans). It is clearly a diagnostic tool, distinguishable in spirit from summarize_dataset or validate_dataset, but it never explicitly names what resource 'path' points to or contrasts itself against those siblings.

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

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

There is no statement of when to choose this over summarize_dataset, validate_dataset, or detect_dataset, nor any preconditions or exclusions. The only usage signal is implicit in the word 'quality', leaving the agent to guess whether this is a pre-flight check, a profiling step, or an anomaly audit.

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

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

With no annotations, the description carries the full burden. "Write a project skeleton" implies filesystem mutation, but it never says whether files are created at 'destination', what happens if the target already exists, or that 'overwrite' exists to allow clobbering — a notable omission for an unannotated write tool.

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

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

A single front-loaded sentence with the verb first and zero filler; the only mild cost is that the parenthetical scaffolding contents are dense and slightly compete with the actionable part.

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

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

A write tool with no annotations, no output schema, and 0% schema description coverage needs the description to cover side effects, overwrite semantics, and destination meaning. It supplies only the kind enumeration, so an agent cannot safely predict what will land on disk before calling.

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

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

Schema coverage is 0% across 4 parameters. The description glosses only 'kind' (and partially at that), leaving 'destination' (directory? path prefix?), 'name' (project name vs folder name vs default value), and 'overwrite' (what it overwrites, and that default false means failure or merge) entirely unexplained.

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

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

"Write a project skeleton" names a specific verb and resource, and the three enumerated kinds ('platform', 'adapter', 'pipeline') make the scope concrete. It is clearly distinguishable from the dataset/catalog siblings, though the parenthetical build descriptions read as content lists rather than a purpose statement.

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

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

No guidance on when to choose scaffold_project over, say, convert_dataset or catalog_index, and no stated preconditions (empty destination, existing project present, permissions). The only selection help is implicit in the 'kind' glosses.

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

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

With no annotations, the description carries the full burden. It explains the algorithmic basis but says nothing about whether it mutates the dataset or returns segments, what the output shape is, or what happens to unsegmented frames — significant gaps for a processing tool.

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

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

Two tight sentences with the action front-loaded and no filler. Efficient, though it is concise at the cost of necessary detail.

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

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

A four-parameter processing tool with no annotations, no output schema, and zero parameter descriptions needs considerably more explanation than two sentences. The agent lacks enough to invoke it confidently.

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

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

Schema coverage is 0% and four parameters exist. The description only loosely gestures at 'feature' via 'feature-speed percentiles'; path, episode, and min_frames (default 5) are left entirely unexplained, so it does not compensate for the schema gap.

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

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

States a specific verb (split) and resource (episodes) with the segmentation criterion (moving/idle via feature-speed percentiles). Sibling tools are dataset-level operations, so there is little confusion risk, but the description does not explicitly differentiate itself from them.

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

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

'Useful for phase labelling and for trimming dead time' implies downstream use cases but gives no explicit when-to-use/when-not guidance or alternatives. An agent must infer the trigger conditions.

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

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

With no annotations, the description carries the full burden; it does well on response contents (it lists the returned fields, which is the key behavioral fact for a read tool). It omits read-only confirmation, requirements on `path` (local dataset root vs file), behavior on unsupported/invalid datasets, and cost when episode rows are included — that last point lives only in the schema.

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

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

Two sentences, zero filler, with the highest-value content (the field list) front-loaded and the usage cue trailing as an imperative. The dense enumeration earns its length because no output schema exists.

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

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

No output schema exists, so the description must explain returns — it does so thoroughly via the field enumeration. The only real hole is the undefined `path` argument, which is important for correct invocation but is the sole gap.

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

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

Schema description coverage is 50%: `include_episodes` is documented ("can be long") but `path` has no description anywhere — the description never says what it points to. The description adds no parameter meaning at all, so it fails to compensate for the gap.

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

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

States a specific verb (summarise) and resource (dataset) and enumerates exactly what the summary contains: format, version, fps, robot type, feature metadata, episode count, frames, duration, tasks, notes. This implicitly distinguishes it from validate_dataset or quality_report, but no sibling is named, so it falls short of the 5 bar.

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

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

"Use before any analysis to learn the schema" gives a clear when-to-use trigger. It does not state when to prefer siblings like detect_dataset or validate_dataset instead, nor any prerequisites, so it is strong context without exclusions.

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

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

With no annotations the description must carry the burden; it does disclose the return shape (severity, stable code, hint, 0-100 score) which is valuable since no output schema exists. It never states that the operation is read-only/non-destructive, whether it writes a report artifact, or how expensive a full run is.

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

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

Two dense sentences, front-loaded with the verb and check list, then the return contract. No filler or redundant restatement.

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

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

For a 3-param, read-only validator with no output schema, the enumeration of checks plus the description of returned issues and score is close to sufficient. Missing only prerequisites and the validate-vs-report relationship to sibling tools.

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

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

At 67% schema coverage the schema explains checks and include_frames, and the description's list of check categories (metadata, vocabulary, episode indices/lengths, fps, layout) indirectly tells the agent what values the checks array accepts. It adds nothing about the required path parameter or the format expectations behind it.

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

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

States a specific verb (Run structural validation) and enumerates the concrete checks performed, which is far more than a restatement of the name. It does not differentiate itself from overlapping siblings such as quality_report or detect_dataset, so an agent still has to infer the boundary.

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

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

No statement of when to use this versus quality_report/detect_dataset, no prerequisites (e.g. must path already be catalogued or converted), and no guidance on cost. The only usage hint ('omit for defaults') lives in the schema, not the description.

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