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

With no annotations, the description carries the full burden and does well: it discloses exactly which aspects are compared (kind, axes, stamps, coordinates, data) and the exact tolerance rule |a - b| <= atol + rtol * |b|. It also pre-empts a likely confusion about non-deterministic ids across hardware. It does not state whether the result is a boolean or a detailed mismatch report, though an output schema exists to cover that.

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, front-loaded with the core action and rationale, with no filler. The second sentence is dense with the comparison tuple and formula, which slightly impedes scanning but every clause 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?

For a 4-parameter comparison tool with an output schema and no annotations, the description covers purpose, motivation for existing, comparison scope, and tolerance semantics. An agent has enough to invoke it correctly; the only omission is explicit identification of a/b as artifact ids and the parameter defaults, which is minor.

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 must compensate. It meaningfully explains atol and rtol via the tolerance formula, which is real value. However, it never states that 'a' and 'b' are artifact ids/hashes (only 'Ids are hashes' is mentioned in passing), nor the defaults of atol=0 and rtol=1e-9, leaving two of four parameters underspecified.

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 ('Check whether two artifacts agree numerically') and immediately scopes it to a concrete scenario ('the same step run on a laptop and on a cluster'). The second sentence distinguishes it from raw identity checking by explaining that artifact ids are hashes of exact bytes, so this tool does semantic/numeric comparison instead.

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 laptop-vs-cluster example gives a clear triggering context for when to reach for this tool. It does not name alternatives or state when-not to use it (e.g. versus inspect_artifact for single-artifact inspection), so the guidance is contextual rather than exhaustive.

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 implies a read-only lookup but never states that, nor does it say what happens with an unknown operation name, whether errors are raised or empty results returned, or how large the documentation payload might 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?

One front-loaded sentence with no filler, which is appropriate for a lookup tool. It is arguably too terse rather than too long, but every word 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 output schema exists, so return-shape explanation is unnecessary, and the description correctly says it returns docs plus JSON schema. However, for a tool whose only input is an undocumented identifier, the missing note on where to obtain that identifier and on error behavior leaves a real 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 coverage is 0% and the single `name` parameter has no description at all. The phrase "an operation's parameters" weakly implies `name` identifies the operation rather than a parameter, but it does not specify the expected identifier format or that it must match an operation from list_operations.

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 a specific resource (an operation) and states exactly what is returned (full documentation plus JSON schema of its parameters), which is enough to distinguish it from list_operations or get_run. It stops short of explicitly contrasting with any sibling, but the verb+resource pairing is unambiguous.

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 when-to-use guidance, no mention of where the required `name` value should come from (presumably list_operations), and no exclusions or alternatives. The agent must infer the entire invocation context.

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 discloses output formats (e.g., .mat layout, table structure) but omits critical write behavior such as overwrite semantics, permissions, or error handling.

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 front-loaded with the action and format options, and is relatively concise. The parenthetical detail about .mat and table formats is useful but slightly dense.

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?

Given no annotations, 0% schema coverage, and an output schema, the description is incomplete: it lacks parameter explanations, usage context, and behavioral details needed for safe and 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?

Schema description coverage is 0%, so the description must explain parameters. It only lists format options (which are already defined as an enum in the schema) and provides no information about the required 'artifact_id' or 'path' parameters.

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 a specific verb ('Write') and resource ('artifact to disk') and lists supported formats. It distinguishes itself from siblings like export_workflow by focusing on artifact export, though it does not explicitly name 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 implies the tool's use for writing artifacts but provides no explicit guidance on when to use it versus alternatives such as export_workflow or import_data. No prerequisites or exclusions are mentioned.

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?

Without annotations, the description usefully discloses execution semantics: each job runs one step against a shared store, pipeline sessions run in parallel, and aggregate steps wait. However, it does not clarify whether this only generates job files or actually submits jobs to the cluster, nor does it mention write side effects, permissions, or failure behavior.

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 purpose and behavioral context are front-loaded, and the per-target option lists are terse. The text is dense but every sentence contributes, though the abrupt switch into option lists could be slightly better signposted.

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 output schema exists, so return values needn't be explained. But for a 4-parameter tool with no annotations and 0% schema description coverage, the description omits top-level parameter meanings and whether the tool submits cluster jobs or only emits job files, which are important 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It helpfully enumerates target-specific `options` keys for slurm and argo, but never explains what `workflow` (object vs string), `target`, or `out_dir` mean, leaving several required parameters undocumented.

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 ('Compile') and resource ('workflow or pipeline into cluster jobs'), making it clear this is a compilation/export operation rather than execution (run_workflow) or validation (validate_workflow). The purpose is distinct from siblings, though it does not name an alternative explicitly.

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 implies usage when preparing a workflow for a Slurm or Argo cluster, but never states when an agent should choose this over run_workflow, validate_workflow, or export_artifact. No explicit exclusions or prerequisites are given.

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 the full disclosure burden. It does reveal the dual fetch/list behavior and the categories of data returned, but says nothing about permissions needed, behavior for an invalid id, or pagination of the list mode.

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 very short fragments with zero filler, and the primary behavior precedes the conditional. The telegraphic style omits a verb and reads as a field list rather than a sentence, which slightly hurts scannability without wasting any words.

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 output schema exists, so return values needn't be detailed, and both modes are mentioned. Still, for a tool with no annotations, the definition leaves gaps around error behavior for a bad id and what the list mode returns.

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 the schema only exposes a nullable dataset_id with a null default. The description partially compensates by explaining that omitting the id switches to list mode, which is genuine meaning beyond the schema, but it never describes the expected id format.

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 the resource and its contents ('A registered dataset's sessions, subjects, attributes and input artifact ids') and reveals a dual mode ('With no id, lists datasets'), which separates it from register_dataset. However, it is a noun phrase with no verb, so 'get' is inferred rather than stated, and it never distinguishes itself from inspect_artifact or list_artifacts.

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 only guidance is the conditional 'With no id, lists datasets', which explains what happens when the parameter is omitted but not when to choose this tool over siblings like register_dataset or list_artifacts. No exclusions, prerequisites, or alternative routing are given.

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, and it delivers the two most important behavioral facts: this is a record-retrieval read, and omitting run_id silently switches the tool into a recent-runs listing mode rather than erroring. It stops short of describing behavior for an unknown run_id or any auth/scoping 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?

Two sentences, zero filler, with the primary purpose and record contents front-loaded and the mode-switch rule placed last where it reads as a qualifier. Every clause adds information an agent would otherwise have to guess.

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 output schema exists, so return-shape detail is not the description's job, and the dual-mode behavior plus record contents cover the essentials for a one-parameter read tool. What is missing is failure behavior for an invalid run_id and any mention of result volume or pagination for the listing mode.

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% for the single run_id parameter, so the description must supply meaning — and it does: the parameter's presence selects single-run lookup, its absence selects recent-runs listing. The only gap is that no format or example for run_id is given.

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 specifies both the verb (retrieve a full provenance record) and the resource (a run), and enumerates what the record contains (resolved workflow, environment/package versions, per-step params/inputs/outputs/cache key). It is clearly not list_artifacts or list_operations, though it never explicitly routes the agent away from 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?

The second sentence usefully explains the no-argument fallback ('lists recent runs'), which is real usage guidance for the optional parameter. However, there is no statement of when to prefer this tool over describe_operation, inspect_artifact, or list_operations, and 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 behavioral burden. It states that the tool imports into the store and returns an artifact id, but it does not disclose permissions, overwrite behavior, error cases, idempotency, or other side effects of a mutation-like import operation.

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 core purpose is front-loaded, then the Series and Intervals paragraphs organize the dense parameter guidance. The description is long but every sentence carries operational meaning for a complex 18-parameter import tool.

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?

The output schema exists, so return-value explanation is not required, and the description covers many parameter semantics. However, for a complex import with no annotations and 0% schema description coverage, it still omits important context such as permissions, overwrite behavior, and handling of unsupported or malformed files.

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 the 18 parameters, and it does so for many of them: data_key, parametric_axis, stamps_key, sample_rate, start, ticks_per_unit, axes, axis, unit, ons_key, offs_key, times_key, stream, and stamp_column. It leaves some parameters such as name and units unexplained, preventing a top score.

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 and resource: import a .npy/.npz/.mat/.csv file into the store and return its artifact id. It is clear what the tool does, but it does not distinguish this tool from nearby siblings such as register_dataset or export_artifact.

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 explains how to shape series and interval imports, but it does not state when this tool should be used versus alternatives such as register_dataset. There are no explicit preconditions, exclusions, or sibling-routing guidance.

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; 'summarise' strongly implies a read-only, non-mutating operation, which is useful. However, it does not state what happens when the prefix is ambiguous or matches nothing, nor any permission or cost characteristics.

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 with no filler: the primary operation and its output content come first, and the identifier-acceptance note is tacked on efficiently. The parenthetical list is dense but each item is meaningful.

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 read tool with an output schema present, the description covers purpose, summary contents and input format, which is sufficient to call it correctly. Missing only edge-case behavior for non-unique prefixes and any note on sibling selection.

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% for the single required parameter, so the description must compensate — and it does, explaining that artifact_id accepts a full id or a unique prefix. The ambiguity/error behavior of the prefix is left unstated, keeping it below 5.

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+resource ('Summarise an artifact') and enumerates exactly what the summary covers (axis, unit, shape, axes, extent, sample rate, NaN fraction, provenance). That enumeration implicitly distinguishes it from list_artifacts, compare_artifacts and export_artifact, but no sibling is named explicitly.

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 only usage-adjacent sentence is about identifier format ('full id or unique prefix'), which is input guidance rather than when-to-use guidance. There is no statement of when this tool should be chosen over describe_operation, list_artifacts or compare_artifacts, and no prerequisites or 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 provided, the description carries the full disclosure burden, and it offers almost nothing: no indication of whether results are paginated, how large the listing may be, what order they come in, or any permission requirements. 'Every artifact' hints at an unfiltered full scan but that is the only behavioral signal.

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 short sentence with the verb and scope front-loaded and no filler. It is not under-specified to the point of being a tautology, but it also has no structure beyond the one clause.

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?

The output schema covers return values and there are no parameters, so the remaining burden is small. However, absent any annotations, the description should say more about the nature of the listing (completeness, ordering, scale) to be fully sufficient.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description adds no parameter information, but none 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 names a specific verb (list) and resource (artifacts) with a clear scope qualifier ('every ... in the store'). An agent can tell what it does, but it does not distinguish this from siblings such as inspect_artifact or compare_artifacts, which also operate on artifacts.

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 use this tool versus alternatives like inspect_artifact or export_artifact, and no prerequisites or exclusions are given. The single sentence only asserts what the tool does, leaving selection entirely to inference.

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 burden, and it does disclose the shape of what comes back (operations plus their input/output kinds). However, it never states that this is a read-only query with no side effects, nor anything about permissions or cost — for a list tool the risk is low, but the disclosure is thin.

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 waste, with the core behavior front-loaded and the optional filter clearly marked as optional. Every clause 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 output schema exists, so the description need not explain return values, and the one parameter's valid values are fully enumerated. The only real gap is the missing handoff to describe_operation, but the tool is callable correctly as written.

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 the single parameter has no description or enum, so the description is the only source of meaning — and it delivers by enumerating the valid categories (intervals, series, filtering, peri-event, correlation, alignment). It does not say whether matching is exact or case-sensitive, which keeps this short of a 5.

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 ('List available operations') and even specifies what each entry contains ('input kinds and output kind'), which is more than the name conveys. It doesn't explicitly distinguish itself from the sibling describe_operation, so the boundary between listing and describing is left for the agent to infer.

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?

'Optionally filter by category' tells the agent filtering is available but not when filtering is warranted versus listing everything. No mention of the natural follow-up (describe_operation) or of any when-not condition, so usage is implied rather than guided.

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 discloses important behavior by saying file inputs are imported and by describing the returned content-derived id as pinning the exact data, but it does not address permissions, idempotency, overwrite behavior, or other side effects of registration.

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 front-loaded with the action and then gives the dataset structure in a single dense sentence. It avoids filler, though the nested brace notation is harder to parse than a more structured presentation would be.

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 tool whose only parameter is a complex nested object, the description supplies substantial structural detail and an output schema covers return values. However, it omits the string alternative permitted by the schema, does not clarify usage relative to siblings, and provides no annotation-level safety context.

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, and it does so extensively by spelling out the nested dataset object: name, sessions, subject, attributes, and inputs with artifact-id or file-path forms. The main gap is that the schema also allows a string dataset, and the description does not explain what that string represents or when to use 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?

The description gives a specific verb and resource: register an experiment/dataset, and outlines the expected object shape. It does not explicitly distinguish this tool from siblings such as import_data or get_dataset, so it is clear but lacks sibling differentiation.

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 explains what the dataset structure looks like, but gives no guidance on when to use register_dataset versus import_data, get_dataset, or other siblings. The note about file inputs and import_data options is structural context, not usage guidance.

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 and does disclose the most important non-obvious trait: caching keyed on (operation, version, params, inputs) with `force` bypassing it, plus the shape of the result. It omits execution characteristics such as duration, failure/partial-failure behaviour, and the cost of a large pipeline run.

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, front-loaded with the action, then the caching caveat and the return shape. No filler or restatement of the name.

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 2-parameter tool with an output schema, the description covers the one genuinely tricky behaviour (cache reuse and `force`) and the return contract. The gap is the ambiguous `workflow` argument type, which neither schema nor description resolves.

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 explains `force` well (bypasses cache), but says nothing about `workflow` being either an inline object or a string — an agent cannot tell whether the string is a path, a name, or serialised JSON.

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+resource ('Run a workflow or pipeline locally') and adds that it returns run_id, per-step outputs and workflow outputs, which separates it from validate_workflow/visualize_workflow/export_workflow. It does not explicitly name any sibling as the alternative, so the differentiation is inferential 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?

Gives a concrete usage scenario — cached step reuse means 'adding sessions to a dataset only runs the new ones' — and explains when to set `force`. It does not tell the agent when NOT to use it (e.g. validate first, or use get_run to re-fetch an existing run), so the guidance is contextual but not exhaustive.

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 and does substantial work: it discloses what is validated, that execution order and per-step output kinds are returned, and that pipelines are compiled first with session steps renamed to '<session>__<step>'. It omits one important behavior: whether failures raise an error or come back as a validation-result payload.

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 with the core action, the accepted input forms, and the output shape, all front-loaded with zero filler.

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 output schema exists, so return format need not be explained, yet the description still summarizes it helpfully. Coverage is strong for a single-parameter validation tool; the only meaningful gap is failure/error reporting semantics.

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 the single anyOf parameter is undocumented structurally, but the description compensates by naming all three accepted forms: a JSON object, YAML/JSON text, or a file path. This directly resolves the anyOf ambiguity the schema leaves open.

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: "Statically check a workflow or pipeline," and enumerates what is checked (references, cycles, input/output kinds, parameters). The word "statically" implicitly separates it from run_workflow, but no sibling is named explicitly.

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 context of use is implied by "statically check" (validate before executing), but the description never says when to reach for this versus run_workflow or visualize_workflow. There are no exclusions, prerequisites, or named alternatives.

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 the full burden. It does add real behavioral context: the tool renders Mermaid for the user rather than returning raw text, and pipeline workflows are collapsed to session steps inside an 'each of N sessions' block with artifact kinds on edges. It does not state whether the operation is read-only/side-effect free, whether invalid workflows error or degrade, or any limits on graph size.

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, front-loaded with the purpose before the format details. The pipeline-collapsing sentence is dense and slightly awkward but every clause carries information an agent would otherwise lack.

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 an output schema present, return-value explanation is unnecessary, and the description covers both input parameters plus the notable rendering convention for pipelines. Remaining gap is guidance on failure modes and interaction with validate_workflow, minor for a read/visualization tool.

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 must compensate, and it largely does: it explains that the workflow argument accepts either Mermaid flowchart text or a node/edge graph as JSON, which maps directly onto the anyOf schema. It also names the rendering intent of each format option. It does not describe the enum's default or error behavior for mismatched format/input.

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?

Opens with a specific verb and resource: "Draw a workflow or pipeline," then names the two output modalities. It is clearly distinguishable from siblings like export_workflow or validate_workflow, though it never explicitly contrasts itself with export_workflow (which might also emit Mermaid).

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 implied through the format distinction — Mermaid text is to be rendered for the user, JSON graph is for a visual editor — which effectively tells an agent which mode to pick. However, there is no explicit when-to-use/when-not guidance relative to export_workflow or validate_workflow, and no stated preconditions (e.g., must the workflow be validated first).

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