Nimbus BCI

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: the anonymous Local Free mode response shape and the fact that hosted tokens expose name and days-until-expiry. It stops short of saying what happens with an expired or invalid token.

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?

Front-loaded with what the caller learns, followed by when to call it and the anonymous-mode caveat. Each sentence carries information, though the multi-clause opening sentence is denser than it needs to 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?

An output schema exists, so return values need not be re-documented, yet the description still previews the key fields including the anonymous-mode variant. For a zero-parameter identity probe, nothing an agent needs in order to call it correctly 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument call, and nothing in it introduces parameter syntax that could conflict with the empty 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?

Names a specific identity resource and enumerates what it returns: account email, plan (isPro / pioneer), free-run quota, and hosted-token name/expiry. No sibling tool covers credentials or session identity, so the scope 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?

Gives explicit triggers: 'Call this first when setup guidance appears' and 'to check which credential a session uses.' It also pre-empts the anonymous case, stating that Local Free mode returns a mode/tier response instead of demanding a login. No alternative tool exists, so no routing is needed.

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?

Goes well past the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by disclosing the concrete output path, the per-source-type conversion semantics (EDF byte-passthrough, HDF5→EDF with events.tsv), the guarantee of no fabricated onsets, and the embedded manifest with sha256 hashes. An agent knows exactly what will be produced and where.

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?

Front-loaded with the core action and destination, then the format-specific behavior in two compact paragraphs. Slightly dense with parenthetical detail, but every sentence carries operational 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?

With an output schema present, return values need not be re-explained, and the description still covers output location, format branching, manifest contents, and zip-size bounding. Nothing an agent needs to invoke it correctly 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?

Schema description coverage is 100%, so the schema already documents dataset, kind, and subjects (including the pack-only subject filter and auto-detection). The description adds no parameter-level detail beyond what the schema provides, which is the baseline-3 case.

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 ("Export a Nimbus dataset as a BIDS-layout zip") plus the output location, which is far more concrete than the title. It does not, however, distinguish itself from the closely named sibling bids.export_execution, leaving the agent to infer the dataset-vs-execution split.

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 source-kind routing (continuous vs epoched, auto-detected) which implicitly tells the agent what this tool handles, but it never states when to choose this over bids.export_execution or pipeline.export, and offers 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?

Annotations already establish the write-but-non-destructive, idempotent profile, so the bar is lower. The description still adds value beyond them by disclosing the exact output manifest and the destination directory (NIMBUS_EXPORT_DIR/bids/), which an agent cannot infer from structured fields. It stops short of noting overwrite behavior or permissions, but with idempotentHint=true that gap is modest.

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 leads with verb, resource, and output shape. The parenthetical file list is dense but earns its place by specifying the deliverable; there is no filler. Slightly list-heavy but well structured.

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-value documentation is not required, and the description already covers the artifact contents and save location. The remaining gap is sibling disambiguation against bids.export_dataset, which leaves the agent slightly under-informed for selection, but the definition is otherwise complete for a one-parameter export 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 100% and the single parameter already carries its own description pointing back to execution.run. The tool description adds nothing about the parameter beyond what the schema states, so the baseline 3 applies.

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 verb (Export) and resource (an execution's results, delivered as a BIDS-derivative zip) are specific, and the enumerated file manifest makes the artifact concrete. However, it never distinguishes itself from the sibling 'bids.export_dataset', whose name suggests an almost identical operation, so an agent cannot confidently choose between them from the description alone.

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 such as bids.export_dataset, pipeline.export, or execution.download_artifact. The only implied guidance is that it takes an execution_id, which the schema already makes obvious. No prerequisites or exclusion conditions 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?

Annotations cover the safety profile (destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description still adds real behavioral value: 'cues hold' describes the state effect on the run and 'resume anytime' confirms reversibility, which is more than the annotations convey.

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 short sentence, front-loaded with the action and resource, with the parenthetical adding effect detail rather than filler. 'Cues hold' is slightly jargon-ish and could be clearer, but nothing is wasted.

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 need no explanation, and annotations carry the safety/idempotency profile. The description covers the action and its reversible state effect, leaving only minor gaps such as interaction with 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?

There is a single parameter with 100% schema description coverage, so the schema already documents execution_id fully. The description adds no format, source, or retrieval detail beyond that, making 3 the correct baseline.

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 (pause) plus resource (calibration) and a scope qualifier ('between trials') that distinguishes it from a hard stop. It does not explicitly name calibration.resume as the counterpart, though 'resume anytime' gestures at it.

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?

'Resume anytime' implies the resume path and that the action is reversible, which is implicit guidance on when this is appropriate. However, it never states when to prefer pause over execution.cancel or calibration.status, so usage is left 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?

Annotations already declare that this is a non-read-only, non-idempotent, non-destructive, open-world operation. The description adds the useful precondition that the session must already be paused, but it does not describe side effects, required permissions, or what happens if the session is not paused.

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 with no wasted words. It communicates the essential action and precondition immediately, which is appropriate for a simple one-parameter 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?

Given the simple one-parameter schema, rich annotations, and presence of an output schema, the description supplies the key state precondition and action needed to invoke the tool correctly. It only omits explicit usage routing among sibling calibration tools, which is a minor remaining 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 100%, and the single parameter execution_id is fully documented as 'The calibration run to resume.' The description adds no parameter-level detail beyond what the schema already provides, so it meets the baseline for high schema coverage.

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 states a specific verb ('Resume') and resource ('paused calibration session'), so the core action is unmistakable. It distinguishes the tool from calibration.pause and calibration.start through the word 'resume' and the precondition 'paused', but does not explicitly name or compare sibling tools.

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 'paused calibration session' implies the context for use: only call this when a calibration session is currently paused. However, it gives no explicit when-not guidance or alternative routing, such as whether to use calibration.start instead when no session exists.

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?

Annotations declare readOnly=false, openWorld=true, idempotent=false, destructive=false, but the description adds genuinely new behavioral facts not in the annotations: the operation is NON-BLOCKING, it is confirm-gated because a device goes on a human's head, the UI cues are handled by the app, and access is gated by freemium node policy with an MCP_LOCAL_IS_PRO condition. This is exactly the value-add the dimension rewards.

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?

Front-loaded with the core action and the non-blocking/confirm-gated traits, then the app/poll note, then the plan gating. The plan-gating sentence is dense and lightly overwrought, but every part carries operational meaning for an agent.

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 14-parameter, open-world, non-idempotent start operation, the description covers the safety gate, the async nature, the follow-up polling tool, and the authorization precondition, and an output schema already exists so return values need no explanation. Nothing essential for correct invocation 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?

Schema description coverage is 100% with 14 documented parameters, so the schema already carries parameter meaning and baseline is 3. The description reinforces the confirm gate but adds no syntax, format, or selection guidance beyond what the schema states for device_type, port, or connection_type.

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 ('Start a guided subject calibration session') and immediately pins the differentiator from siblings by pointing to calibration.status for progress. An agent knows exactly what this does and what to call next without opening the schema.

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 clear usage context: it is non-blocking, confirm-gated, and the app renders cues automatically so the caller should poll calibration.status. It also states the plan precondition (Pro/token or Pro session). It stops short of contrasting with calibration.train or explaining pause/resume interplay, so not a 5.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond the annotations: that the snapshot is 'live' and that after completion it 'carries the recorded upload,' which tells the agent the object's payload changes with session state.

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: the resource and its returned fields are front-loaded, followed by the completion/follow-up behavior. No wasted phrasing.

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?

Output schema exists, so return values need not be spelled out; the description covers purpose, state contents, and the follow-up action. Nothing an agent needs to invoke it correctly 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?

Single parameter with 100% schema description coverage; the schema already explains execution_id including its origin (from calibration.start). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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 resource and action ('Live snapshot of a calibration session') and enumerates what it exposes (phase, current trial, progress, paused), so the agent knows exactly what this returns. It is clearly the read/status member of the calibration.* family, distinct from pause/resume/start/train.

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?

Provides clear forward context: 'Once complete... call calibration.train to turn it into the subject's own classifier,' which routes the agent to the correct next tool. It stops short of stating when to use this vs other status-like siblings (e.g., stream.status, execution.get), so no explicit 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?

Adds substantial behavior beyond the annotations: it declares the call is NON-BLOCKING (async), discloses the freemium/Pro gating, and explains the calibrate→train handoff resolution including the edge case where pre-build recordings resolve no upload. These are exactly the operational facts an agent cannot infer from readOnly/openWorld/idempotent hints.

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?

Front-loads the core action and keeps detail tight across a few sentences, with the caveat placed last. It is somewhat dense in the trailing handoff/edge-case clause, but every part is load-bearing for correct invocation.

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 and annotations carrying the safety profile, the description fills the remaining gaps: required state (completed session), plan gating, async nature, and failure/precondition edge cases. An agent has everything needed 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 100%, so each parameter is already self-documented. The description lightly reinforces the custom_data rewiring that relates to train_graph, but adds no per-parameter syntax or format detail, so the baseline 3 applies.

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 (Train) and resource (the subject's own classifier) plus the exact source (a COMPLETED calibration session), and describes the mechanism (fetch upload, wire as custom_data source, start run). An agent can distinguish this from siblings like calibration.start/status and execution.run without opening the schema.

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 clear prerequisites — a COMPLETED session and a Pro plan — and a concrete fallback ('rerun calibration.start') for recordings made before the execution-linkage build. It stops short of explicitly contrasting with alternative training paths (e.g. execution.run or template-based flows), so no exclusions 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds domain context ('curated', 'MOABB packs', 'available to pipelines'), but says nothing about result size, filtering behavior, or how the on-disk vs known-but-missing distinction surfaces — though the output schema likely covers the shape.

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 tight sentence with the resource front-loaded and no filler. It is appropriately sized for a simple listing tool, though it is arguably too terse to convey the listing action explicitly.

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 an output schema exists and annotations declare the read-only safety profile, the description need not explain return values. However, for a catalog entry point it provides no indication of scope (how many datasets, filtering options) or relationship to sibling catalog tools, leaving a modest 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 100%, and the only parameter (only_on_disk) is well documented in the schema with its default and behavior. The description adds no parameter-level meaning beyond that, so the baseline of 3 is appropriate.

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 identifies the specific resource — curated public EEG datasets (MOABB packs) — and the phrase 'available to pipelines' implies a listing operation. It distinguishes from siblings like catalog.nodes or catalog.templates by naming the resource domain, though it never states an explicit verb like 'list' or 'retrieve'.

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 and no mention of alternatives such as data.inspect_dataset for drilling into a specific set. An agent must infer that this is the entry point for discovering datasets, without any routing help.

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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is fully covered. The description adds substantial domain context (tracks, BYO rows, the pretrainedFewTrial efficiency track), but none of it is behavioral — no auth, rate-limit, or side-effect information beyond what the hints provide.

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?

It is front-loaded with the purpose, which is good, but then spends most of its length documenting return-value fields (rows, packFingerprint, updated, ciLoPct/ciHiPct) that the output schema already carries. Several sentences could be trimmed without losing anything an agent needs to invoke the 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?

With an output schema present, the description needn't explain return values yet does so thoroughly, so the calling context is more than complete. The only gap is guidance on choosing this tool over its leaderboard siblings, which leaves the picture slightly incomplete for tool 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 100% and the single optional dataset_id is fully documented in-schema ('When set, every track is filtered to that dataset. Omit it for the full board.'). The description mentions datasets repeatedly but adds no filtering semantics beyond the schema, so the baseline 3 applies.

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 opening sentence gives a specific verb and resource: 'Public benchmark leaderboard: pipeline rankings per dataset.' It implicitly distinguishes itself from leaderboard.submit by noting that submittableDatasets are 'open for leaderboard.submit,' but it never contrasts with siblings like leaderboard.mine or leaderboard.status, so an agent still has to infer which leaderboard tool to pick.

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 by the resource name — the description never says when to call this versus leaderboard.mine, leaderboard.status, or plots.leaderboard. The one useful routing hint is that submittableDatasets marks what leaderboard.submit accepts, but there are no exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds no behavioral context beyond that — nothing about return shape or filtering semantics — so with annotations doing the heavy lifting a 3 is appropriate.

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 verb and resource, followed immediately by the disambiguation. 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 values need not be described, and the input schema is fully documented. The only mild gap is that nothing tells the agent what the unfiltered call returns versus a filtered one, but that is covered by the output schema.

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 100% and the single `category` parameter is documented in the schema, including that it takes exact category ids from the unfiltered list. The description's category examples duplicate that, so baseline 3 applies.

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 Nimbus pipeline node types') and enumerates the domain ('data, preprocessing, features, models...'), so an agent immediately knows the scope. It also names the sibling it is not (catalog.node_schema) which handles single-node detail.

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 routes the agent: use this tool to enumerate node types, use catalog.node_schema for one node's full config schema and ports. That is clear context selection guidance, though there are no explicit exclusions or prerequisite 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?

Annotations already establish readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful content-level detail (config schema, ports) but says nothing about error behavior for an unknown node_type or how large the payload can be, leaving behavioral gaps.

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-fragment with zero filler, sized appropriately for a one-parameter lookup tool. It is a noun phrase rather than a sentence, which slightly reduces immediate readability.

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, the description need not explain return values, and it correctly signals the scope (one node type). For a read-only, single-param tool this is nearly complete, missing only failure behavior for an unrecognized node_type.

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 100% and the single parameter is documented in the schema, including examples ('csp', 'nimbus_lda') and its provenance from catalog.nodes. The description adds no meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 ('node type') and states precisely what is returned: the full config JSON schema plus input/output ports. It is clearly distinct from the list-oriented siblings catalog.nodes and catalog.templates, though it never names those siblings to make the contrast explicit.

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: the node_type parameter's reference to catalog.nodes hints at a discover-then-inspect workflow, but the description never states when to call this versus catalog.template, pipeline.validate_node, or the list tools, and gives no preconditions.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the key content detail that the 'train' execGraph is included, but does not disclose authentication needs, rate limits, or other behavioral traits beyond the annotations.

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 efficient sentence with no wasted words, front-loading what the template contains. It could be slightly clearer with an explicit action verb, but it is appropriately sized.

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 need not be explained, and annotations cover the safety profile. The description states the key content and usage context, making it complete enough for a simple read-only retrieval, though it stops short of contrasting with the similar catalog.templates sibling.

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 100%, and the single template_id parameter is fully documented with an example in the schema. The description adds no further parameter meaning, so the baseline 3 is appropriate.

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 identifies the resource as the full template and specifies that it includes the 'train' execGraph. It is clear what the tool returns, but it lacks an explicit verb and does not directly distinguish itself from the sibling catalog.templates.

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?

It states the tool is needed by execution.run and pipeline.validate, giving a concrete usage context. It does not provide exclusions or explicitly compare against alternatives such as catalog.templates.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only that the pipelines are 'built-in' and static; it says nothing about pagination, caching, or auth needs, but with annotations and an output schema present the burden is lower.

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, purpose front-loaded, zero filler. Every clause either names the resource or routes to the correct sibling.

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 no-arg list tool with an output schema and full annotation coverage, the description supplies what is needed to select and invoke it. A note on whether the list is static versus user-extensible would have closed the remaining 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 (List) and resource (built-in starter pipelines) with concrete examples (MI/P300/SSVEP). The second sentence routes the agent to the singular sibling catalog.template for the actual graph, which helps distinguish it from catalog.template.

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 rather than stated: the parenthetical about catalog.template(id) hints that this tool is for browsing and the singular is for fetching a graph, but there is no explicit when/when-not guidance 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?

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds real behavioral depth beyond them: exactly what is removed (disk + registry), a mandatory confirmation gate, the ownership/authorization boundary, and the not-found failure behavior for missing paths.

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?

Four short, front-loaded sentences: purpose first, then the confirmation gate, then the parameter provenance, then the ownership/error constraint. Nothing is redundant or 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?

An output schema exists, so return values need not be explained. The description covers the remaining agent-critical concerns for a destructive two-parameter tool: authorization scope, confirmation requirement, and not-found behavior.

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 100%, so both 'path' and 'confirm' are already documented in the schema, including that confirm MUST be true. The description restates the same requirements (confirm=True, path from data.upload) without adding format or edge-case detail, so baseline 3 applies.

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 ('Delete an uploaded file'), plus scope ('from your account (disk + registry)'), which cleanly separates it from the sibling data.upload and data.inspect_file. An agent can tell what it does without opening the schema.

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 the prerequisite ('Requires confirm=True') and the input provenance ('Pass the path returned by data.upload (file.path)'), plus a constraint ('Only your own uploads can be deleted'). It stops short of naming alternatives or explicit when-not conditions, so it is clear context rather than full 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?

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description goes beyond them with real operational context: subject is REQUIRED and the backend 400s without it, and values are ASSUMED volts so µV-native files read 1e6x too large, with the unitsScale fix named. It does not describe cost or latency, but the added caveats are substantial.

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?

Front-loaded with what the summary contains, then rationale, then hard preconditions. Dense and slightly parenthesis-heavy (the units aside is long), but every sentence carries information an agent needs and nothing is redundant.

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 structure needn't be explained, and annotations cover the safety profile. The description still supplies the precondition (subject required), the subject-sourcing path, the mode enumeration, and the units pitfall — everything needed to call it correctly the first time.

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 100% so the baseline is 3, but the description adds meaning beyond the schema: the 400 error consequence of omitting subject, the cohort semantics of a comma-list ('S01,S03'), and the units-scale caveat tied to downstream config. That is a genuine increment over the schema's own text.

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 ('Exploratory summary of a public EEG dataset') and enumerates exactly what is produced: channels, sampling rate, trial/class balance, per-channel µV stats, band powers, PSD overview. This distinguishes it from the sibling data.inspect_file, which covers files rather than packed datasets.

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?

Explicitly tells the agent to run it BEFORE building pipelines and gives the reason (class balance drives stratification; flatlined channels signal a montage/reference problem). It also routes to catalog.datasets for the subject list, naming both the when and the alternative source.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds substantial non-obvious behavior: absolute paths are local-backend-only, hosted backends refuse them and return guidance, and the loader ASSUMES volts so a µV-native CSV reads 1e6x too large (with the unitsScale remedy). These are exactly the operational gotchas annotations cannot convey.

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?

Front-loaded with the summary of what is returned, then the path-resolution rule, then the when-to-use rationale and units caveat. Every paragraph carries information, though it is on the longer side and the parenthetical asides could be tightened.

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 need not be documented, and annotations carry the safety profile; the description nonetheless covers purpose, path semantics, backend constraints, and the units pitfall. Nothing an agent needs to call this correctly 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?

With one parameter at 100% schema coverage, the baseline is 3, but the description goes beyond the schema by explaining the consequence of each path shape — absolute means no upload needed but local-only, relative is the value data.upload returns and works anywhere. That adds actionable meaning rather than restating 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 specific verb (exploratory summary / inspect) and resource (EEG file) and enumerates the supported formats (.edf/.bdf/.mat/.csv/.tsv/.txt/.h5) plus the actual content of the summary (channels, sampling rate, trial/class balance, per-channel µV stats, band powers, PSD). This lets an agent distinguish it from data.inspect_dataset without opening either schema.

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?

Explicitly tells the agent to inspect data BEFORE building pipelines and explains why (class balance drives stratification, flatlined channels signal a montage/reference problem). It also clarifies which path form to use on which backend. It does not, however, name sibling alternatives like data.inspect_dataset, so it stops short of the top tier.

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?

Annotations declare the write/open-world/non-idempotent/non-destructive profile, and the description adds beyond that: a 500MB size cap and an explicit rejection policy ('no silent 250 Hz assumption') for missing metadata. It does not cover overwrite behavior for an existing dataset_name or auth requirements, keeping it below a 5.

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?

Three tight sentences, front-loaded with the action and constraints, with no wasted prose. The extension list duplicates the schema's file_path description, which is the only mild redundancy.

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 an upload tool with an output schema that already describes the returned path, the description covers everything needed to call it correctly: accepted formats, size limit, format override, and the conditional sampling_rate requirement. Nothing material is left for the agent to guess.

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 100%, so the baseline is 3, but the description adds real semantics: sampling_rate is only required for plain CSV/TSV/TXT without embedded metadata and the call is rejected otherwise, and format's allowed values are spelled out as an override of detection. dataset_name's purpose is left to the schema alone.

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 (upload), resource (EEG file), accepted formats, size limit, and the tangible outcome ('get the registered path for a custom_data node'). An agent can distinguish this from sibling upload-adjacent tools like data.delete_upload and data.inspect_file without opening any schema.

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 conditional usage rules: sampling_rate is REQUIRED for headerless CSV/TSV/TXT and uploads lacking it are rejected, and format overrides extension detection. It stops short of naming alternatives or stating when not to use this tool versus inspect/delete siblings, so it is clear context without explicit exclusion routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description does add one useful piece of context, that this is the set of devices the backend supports (a static capability list) rather than currently connected hardware, but it says nothing about pagination or refresh 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?

A single short sentence with the resource stated first and examples in parentheses; nothing is wasted and nothing is buried.

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, the description need not enumerate return values, and it correctly identifies the content of that output. For a zero-parameter read-only listing tool this is nearly complete, missing only a one-line pointer to when the list should be consulted.

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 no parameter semantics to explain and the baseline of 4 applies. The description correctly neither invents inputs nor misleads about filtering options.

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 specific resource (EEG devices supported by this backend) and enumerates concrete examples (OpenBCI, Muse, BrainBit, LSL, PiEEG), so an agent can tell it apart from device.test at a glance. It is a noun phrase rather than a verb+resource, but the intent 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 statement, no mention of prerequisites, and no reference to alternatives such as device.test or stream.start. An agent must infer from the name alone that this is a discovery call made before configuring a stream.

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?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered by structured data. The description adds only the 'no confirm needed' nuance, which largely restates the readOnly/non-destructive hints, and says nothing about latency, failure modes, or what a successful test implies.

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 sentence with the key constraint front-loaded and no filler. The capitalized WITHOUT emphasizes the discriminating behavior efficiently.

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 a full output schema and complete annotation set, the description doesn't need to explain returns or safety. It is nearly sufficient, only lacking a pointer to device.list for valid device_type values and any note on what a failed test looks like.

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 100% and every one of the 9 parameters carries its own documentation (port, ip_address, mac_address, connection_type, etc.), so the schema does the heavy lifting. The description contributes no parameter-level meaning beyond that, which is the baseline case.

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 (test) and resource (device connection) and immediately contrasts with stream.start by saying it does NOT start a stream. That is a clear, distinguishable purpose, though it doesn't reference the device.list prerequisite that supplies device_type.

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 explicit context for when to use it (probing a connection without a stream) and implicitly routes away from stream.start for actual data capture. No explicit when-not or named-alternative phrasing, so it falls short of a 5.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context about artifact types (models/filters, *.pkl) but does not disclose pagination, auth requirements, or other behavioral traits beyond annotations and the output 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?

The description is a single tight sentence with no wasted words, and the core resource meaning is front-loaded. It is slightly under-specified as a fragment rather than a complete operational sentence.

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 read-only listing tool with a full parameter schema, rich annotations, and an output schema, the description supplies the key domain context about what artifacts are. It is complete enough for correct invocation, though sibling routing is absent.

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 100% and the single execution_id parameter is fully documented as the run whose artifacts to list. The description does not add syntax, format, or constraints beyond what the schema already provides, so the baseline of 3 applies.

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 and scope: trained artifacts (models/filters, e.g. *.pkl) saved by an execution. It is clear what the tool returns, though it does not explicitly state a verb like 'list' and does not differentiate itself from sibling execution.download_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?

No when-to-use guidance is provided. The description implies artifacts belong to an execution but never says when to call this tool versus execution.download_artifact, execution.results, or execution.get.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of irreversibility, auth requirements, or what happens to partial results of the cancelled 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?

A single front-loaded sentence with zero waste. It is arguably too terse for a destructive operation, but it is appropriately sized and structured.

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 and annotations covering the safety profile, the description need not explain return values. However, for a destructive, non-idempotent operation it omits what cancellation actually does to the run, leaving a meaningful 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 100% and the single parameter already documents its origin (from execution.run/execution.list). The description adds no meaning beyond the schema, so the baseline of 3 applies.

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 (Cancel) and resource (running execution), which is clearly distinct from siblings like execution.run and execution.list. It does not explicitly name or contrast with siblings, so it falls 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 word 'running' implies a precondition (only in-flight executions can be cancelled), which is a weak usage signal. There is no explicit when-to-use, when-not-to-use, or reference to an alternative such as stream.stop.

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?

Annotations already declare openWorldHint, idempotentHint, and destructiveHint=false; the description adds the concrete write destination (NIMBUS_EXPORT_DIR/executions/<id>/) and that a path is returned, which is useful context. It does not state what happens on overwrite or on a missing artifact, so it goes beyond annotations only modestly.

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 sentence that front-loads the action and includes both the destination and the return value; nothing is wasted for a two-parameter 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?

An output schema exists and the description still usefully states the returned path; the destination directory is spelled out, covering what an agent most needs. Only minor gaps remain (overwrite/invalid-artifact behavior), which are not required given the annotation and output-schema coverage.

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 100% and both parameters are documented in the schema, including the example file name and the link to execution.artifacts. The description adds only the <id> path substitution, so the baseline 3 applies.

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 (download) and resource (one artifact file) plus the destination directory, so the agent can tell it apart from listing tools like execution.artifacts. It does not name a sibling alternative explicitly, but the singular 'one artifact file' versus a bulk export is clear.

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 prerequisite (e.g. the artifact must already have been listed via execution.artifacts), and no mention of alternatives such as bids.export_execution or bids.export_dataset. Only the implied 'you need a single file' context is conveyed.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added behavior is enumerating the returned status values (running/completed/failed/cancelled), which is useful but thin given an output schema also exists.

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 zero padding, front-loaded on the resource and its output. It is efficient, though arguably too terse to carry routing 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?

With an output schema present, return-value detail needn't be repeated, and the single required parameter is fully documented. The notable omission is sibling routing (when to pick this over execution.list/results), which keeps it short of a 5.

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 100% and the schema already explains execution_id and its provenance (from execution.run/execution.list). The description adds nothing about the parameter, so the baseline 3 for a fully documented schema applies.

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 ('Execution status summary') and gives the possible status values, so the agent knows it retrieves run state rather than logs or artifacts. It does not, however, distinguish itself from close siblings like execution.list, execution.results, or stream.status.

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 execution.list, execution.results, or stream.status. The only hint of context is the parenthetical status list, which implies polling for a run's state but never says so explicitly.

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?

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds the recency scope and enumerates valid status values, which is useful, but says nothing about pagination, ordering, or whether 'recent' is time-bounded.

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 fragments, front-loaded and free of filler. It is efficient, though the terseness borders on under-specification rather than tight writing.

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 values need not be explained, and annotations cover safety. However, the description never mentions the limit parameter or defines what 'recent' means, leaving gaps for a listing tool with no required params.

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 100%, so both limit and status are already documented in the schema; the description repeats the status enum rather than adding syntax or default behavior. Baseline 3 applies when the schema does the heavy lifting.

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?

'Recent executions' identifies the resource but never uses an explicit verb like 'list' or 'retrieve'. It is distinguishable from execution.get (single run) only by inference from the sibling name, not from the description itself.

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 versus execution.get, execution.results, or execution.artifacts. The word 'Recent' hints at a recency scope but no alternative is named and no condition is 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait beyond that: the default response is trimmed, and the parameters state exactly which fields the trimmed view contains and when to opt into the full object.

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 core purpose, followed immediately by the default-vs-full behavior. Every clause earns its place with no repetition of the name or 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?

An output schema exists so return structure need not be explained, and annotations cover the safety profile. The description supplies the one thing structured fields cannot: the trimmed-by-default behavior and the field list of the default view, making it sufficient 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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining what the default (full=false) actually yields — the trimmed field list — which the schema does not document. It thus characterizes the negative case of a boolean flag rather than merely repeating its description.

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 specific resource (metrics) and scopes it to a completed run, and even enumerates the default payload fields (accuracy, kappa, ITR, confusion matrix, per-class). It is clear what the tool returns, though it does not explicitly contrast itself with the nearby execution.get or execution.artifacts 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 description implicitly guides the agent on the default vs. detailed retrieval mode ("Trimmed by default... full=True returns the complete result object"), which is useful. However, it gives no explicit when-to-use guidance relative to alternatives such as execution.get, nor any prerequisites (e.g., that the run must have finished).

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?

Annotations already declare readOnlyHint=false and idempotentHint=false, but the description adds material behavior the annotations cannot: the call is asynchronous, it returns an executionId for polling, and a duplicate graph still starts (with warning + duplicateOf ids) with a stated cost consequence ('avoid paying twice'). That is exactly the extra context this dimension rewards.

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?

Three tight clauses, all front-loaded: what starts, the non-blocking contract plus executionId, and the duplicate-run edge case. No sentence is filler; each carries a distinct operational fact.

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 an async, potentially expensive, non-idempotent operation, the description supplies the async workflow, the polling/id-termination contract, and the duplicate-detection behavior. With an output schema present it need not describe return shape, so nothing an agent needs to call this correctly 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?

Schema description coverage is 100% and every field (name, layout, subject, description, train_graph) is documented in the schema itself. The description adds no parameter-level syntax or format detail, so the baseline of 3 applies.

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 ('Start a pipeline run') and immediately marks the execution mode (NON-BLOCKING). It also names the sibling tools that carry the workflow forward, so an agent can tell it apart from execution.get/results/cancel without opening a schema.

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?

Explicitly prescribes the follow-up chain: poll execution.get() until completed/failed, then call execution.results(). It also names execution.cancel as the remedy for a duplicate run, giving clear when-to-use routing rather than leaving it 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?

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds substantial context beyond annotations: aggregation semantics (completed runs only, population std, None below 2 values), always-present kindBreakdown, and cross-machine storage/portability behavior for experiments stored server-side versus local-only legacy experiments.

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 snapshot contents and uses clear sections for return semantics and portability. It is dense and includes issue references (#470, #518) that are not directly useful for tool invocation, but the information is structured and most sentences carry operational meaning.

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 the tool is read-only and the input schema is simple, the definition is more than complete. It covers return-value semantics, aggregation rules, storage portability, and historical-data limitations, leaving the agent well-equipped to interpret results correctly across environments.

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 100%, and the single parameter experiment_id is already documented as coming from experiment.run. The description does not add further meaning or formatting guidance for that parameter, so the schema carries the full parameter semantics.

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 identifies the resource as an experiment snapshot and specifies the exact contents: status, per-run rows, and aggregate metrics. However, it does not explicitly state 'retrieve' or distinguish this retrieval tool from the closely named sibling experiment.run beyond the schema note that the ID comes from experiment.run.

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 this tool versus alternatives such as experiment.run, execution.get, or execution.results. The portability paragraph explains storage behavior but does not tell the agent when this tool is the right choice.

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?

Annotations declare non-readOnly, non-destructive, non-idempotent, open-world, but the description goes well beyond them: concurrency clamp min(max_concurrent, 2), up to 3 queue-full retries per run, background-thread polling to completion, and write-through to the Nimbus server with the #518 failure caveat. It does not state whether runs are cancelled/cleaned up on failure, so not a full 5.

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?

Front-loaded with the core behavior in the first sentence, then a labeled PORTABILITY block. Dense but structured; the parenthetical formulas and issue reference (#518) add implementation detail that is useful but slightly noisy for a tool-selection description.

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-value explanation is not required, yet the description still covers return (experimentId), async lifecycle, retries, and cross-entry-point visibility — everything needed to call and follow up correctly. Minor gap: no mention of failure/partial-completion 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 100%, so both parameters are already documented; the description's mention of 1-25 runs and max_concurrent largely repeats the schema. It adds only marginal framing (the concurrency formula and pacing intent) beyond the structured fields.

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+resource+scope: 'Run 1-25 pipelines as ONE paced experiment (NON-BLOCKING)' tells the agent exactly what it does and how it differs from the singular execution.run it references for graph shape. The batching and pacing scope is unique in a sibling set full of single-run and status tools.

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 the operating model explicitly: returns experimentId immediately, then directs the agent to 'Poll experiment.get() for per-run status and, once finished, aggregated metrics.' The portability paragraph tells the agent when get() will and won't work (server unreachable → local-only reads), which is genuine when-to-use 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?

Annotations cover the safety profile (readOnly, non-destructive, idempotent), and the description goes well beyond them: it discloses failure handling ('noted, not silently skipped'), the exact processing pipeline (frozen embeddings via foundation_features preprocessing, cross-validated LDA), and the full return shape (PNG + JSON block + structuredContent.meta.results). This is unusually rich behavioral context.

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?

Purpose is front-loaded in the first sentence, followed by edge-case handling, mechanism, and output format — each sentence earns its place. It is slightly dense in the output sentence (listing three return channels) and the 'not vibes' aside is stylistic, but not wasteful.

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 a full output schema, 100% param coverage, and annotations present, the remaining burden is explaining what the tool computes and returns — which the description does thoroughly. Nothing an agent needs to call it correctly 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?

Schema description coverage is 100%, so source/path/dataset/subject/mode are already fully documented in the schema. The description adds no parameter-level detail, which is acceptable given the schema does the work — baseline 3.

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 — run every pretrained backbone on the user's data and rank them — with concrete outputs (bar chart, CI whiskers, params, wall time). It is clearly a benchmarking/comparison tool, distinguishable from execution.run or calibration.train among the 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 closing phrase 'pick the foundation_features backbone by measurement, not vibes' implies the use case (choose a backbone before committing to one), but it never names an alternative tool or states when NOT to run it. Usage is inferable rather than explicit.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description usefully adds ordering ('newest first') and unfiltered dataset scope, but says nothing about pagination or result limits for a listing call.

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 tight sentence that front-loads the action and resource, then qualifies scope and ordering. No wasted 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 need no explanation, and with no inputs and full annotation coverage the definition is nearly self-sufficient. Only pagination/volume behavior is left unstated.

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 the baseline is 4. There is nothing for the description to clarify, and it correctly avoids inventing 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?

States a specific verb and resource ('List your leaderboard submissions') with scope ('all datasets') and sort order ('newest first'). It implicitly distinguishes itself from catalog.leaderboard and leaderboard.submit via 'your', but never names a sibling to route against 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 word 'your' implies this is the personal-view counterpart to catalog.leaderboard, so when-to-use is inferable but not stated. No explicit exclusions or alternatives 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?

Annotations already cover the read-only, idempotent, non-destructive safety profile, so the description is free to add value elsewhere and does: it discloses the four possible status values, what is returned on success, and that failures surface the error. It stops short of describing polling cadence or whether status transitions are eventual.

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?

Front-loaded with the purpose in the first clause, then the return shape. Tight and waste-free, though the parenthetical aside about matching 'leaderboard rows' assumes knowledge of another tool's shape.

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 need not be enumerated, yet the description summarizes them anyway, which is a bonus rather than a gap. Combined with the one-parameter schema and full annotation coverage, an agent has what it needs to invoke this 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 coverage is 100%, so the single parameter and its provenance are already documented in the schema. The description's only addition is the ownership constraint ('one of your'), which is minor; baseline 3 applies when the schema carries the parameter load.

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 clear verb and resource ('Fetch one of your leaderboard submissions') and adds an ownership scope ('owner-only'), which separates it from leaderboard.mine (list) and leaderboard.submit (write). It does not name those siblings explicitly, so an agent must infer the distinction from the namespace.

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 ('one of your submissions', owner-only) but never states when to call this versus leaderboard.mine to enumerate submissions first. The only routing cue, that submission_id comes from leaderboard.submit, lives in the schema rather than the description.

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?

Well beyond the annotations, it discloses scoring latency (minutes to tens of minutes), the requirements constraint (max 20, plain PyPI specs, no URLs), the identity requirement for anonymous callers, and tier-gated behavior on the hosted backend. One tension: it claims identical-code resubmission is idempotent per track while the annotations set idempotentHint=false; the per-track dedup is a narrower statement than the tool-level hint, so it reads as clarification rather than flat contradiction, but it does muddy retry-safety reasoning.

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 first paragraph is tightly front-loaded and earns every sentence, but the verification-contract paragraph is dense with insider phrasing ('tier model X10', 'designed Account-Free lane', 'no row is faked') and partly restates the verification parameter's own schema description, and the trailing note about local backends' quota behaviour is tangential.

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 an 11-parameter tool spanning server-side, BYO-backbone, and local lanes, the description covers identity requirements, latency expectations, deduplication, tier limits, and where the dataset whitelist lives; return values are carried by the output schema, so nothing an agent needs before calling 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?

Schema description coverage is 100%, so the baseline is 3, and the description adds a constraint not present in the schema: requirements must be plain PyPI names/specs, max 20, no URLs. The verification parameter is also explained in prose (Pro-only on hosted, structured tier response for free accounts) rather than only as a restatement of the enum values.

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+scope: 'Submit a BYO python_model to a leaderboard track for server-side scoring,' and immediately clarifies the core contract ('you submit code, never results'), which separates it from result-oriented siblings like leaderboard.mine and leaderboard.status.

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?

Routes the agent to concrete alternatives and next steps: poll leaderboard.status with the returned submissionId, validate code with python.validate, and source dataset ids from catalog.leaderboard submittableDatasets. It also spells out which verification lane applies to which account type, though it never frames an explicit 'do not use this tool when…' rule.

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?

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is already covered. The description adds where the artifact lands ('zip saved locally'), which is useful, but omits any save path, overwrite behavior, or naming/conflict handling for the produced file.

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 that names the action, the produced artifact, and its form 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?

With an output schema present, return values need not be explained, and annotations carry the safety profile. The definition covers the essentials for a two-param export, but is slightly thin on where/how the bundle is persisted given the openWorldHint.

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 100%, so both parameters are already documented in the schema ('name' recorded inside the bundle; 'train_graph' nodes/connections). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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 (Export) and resource (the pipeline) plus the concrete output artifact (standalone runnable Python bundle, zip saved locally). An agent can distinguish it from pipeline.validate, though it doesn't explicitly contrast with that 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?

No when-to-use guidance, prerequisites, or named alternatives. Siblings like pipeline.validate and bids.export_dataset exist and the description never says when export is the right choice versus them.

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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds the pre-execution intent and the graph shape, but says nothing about what a failed validation returns or how validation is scoped (e.g., config-level checks).

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?

Front-loaded with the core purpose, then supporting input documentation. Three compact lines with no filler, though the 'ExecGraphSnapshot:' shorthand is a bit cryptic for an agent that hasn't seen the type elsewhere.

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 need not be explained. Given annotations covering safety and the description covering purpose, input structure, and construction path, an agent has enough 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 coverage is 100% but the schema is loose (additionalProperties: true, no field definitions). The description compensates by specifying the actual structure - nodes with {id, type, config} and connections with {from, to} - which the schema does not provide.

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+resource combination: validate a pipeline graph, with the added scope of 'before running'. It clearly separates from generic validation, though it doesn't explicitly name pipeline.validate_node to disambiguate graph-level vs node-level validation.

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?

'before running' establishes clear context for when to call it, and it suggests the input source (catalog.template(id).train or catalog.nodes()). No explicit when-not or alternative routing to validate_node, so it stops short of a 5.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description needn't restate it. It adds real behavioral value by naming the failure classes it detects (inverted bandpass, CSP components vs channel count). It still doesn't say whether all errors are returned at once or validation short-circuits, which keeps it out of the top band.

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, purpose front-loaded, and the second sentence is purely additive detail (error types + sibling equivalence). No filler, nothing repeated from the schema.

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 a rich schema, an output schema, and full annotations, the description only needs to explain intent and differentiators, which it does. The one small gap is behavior on multiple simultaneous errors, but return format is covered by the output schema.

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 100%, so node_type, config, and dataset are already documented, including the dataset's channel/sampling-rate role. The description only lightly reinforces this with 'when dataset is set'; baseline 3 is appropriate since the schema carries the semantics.

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+resource ('Validate one node's config') with the scope narrowed to a single node and clarified as schema + semantic checks. It explicitly distinguishes itself from pipeline.validate by saying it catches the same errors 'for a single node', so an agent can separate the two without opening either schema.

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?

It clearly routes against the sibling: pipeline.validate covers the whole pipeline, this covers one node, and the phrase implies using this when validating an isolated node. There is no explicit 'use when'/'do not use when' exclusion or a statement about when the broader validation is preferred, so it stops short of full 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?

Annotations already cover the safety profile (idempotent, non-destructive, open-world). The description adds genuinely new behavioral context beyond them: the output is a PNG the assistant can visually inspect. It does not explain the readOnlyHint=false asymmetry or the on-disk write behavior (deferred to the schema), so it stops short of 5.

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 zero waste; the purpose is front-loaded and the usage hint follows, each sentence pulling weight.

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-shape detail is unnecessary, and the description completes the picture with purpose, visual output, and sequencing. The only minor gap is the absence of any caveat about the matrix default or failure modes on CV runs, which the schema handles instead.

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 100%, so the schema fully documents save, matrix, and execution_id. The description adds no parameter syntax or format detail beyond that, making the baseline 3 correct.

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?

Names a specific resource (confusion-matrix figure for one execution) and describes its concrete composition (heatmap with trial counts plus per-class accuracy bars). It is readily distinguishable from siblings like plots.dataset, plots.erp, and plots.leaderboard.

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 explicit workflow placement ('use it right after execution.results') and names the goal it serves ('eyeball WHICH classes are confused, not just the accuracy number'), routing the agent away from a bare accuracy read. No explicit when-not-to-use or named alternative is given, keeping it just below the top band.

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?

Annotations already declare idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is largely covered. The description usefully adds rendering behavior (Welch PSD with channel mean bold, dB heatmap, time-frequency for one channel), but it never mentions that the optional save flag writes a PNG to disk, which is the one side effect behind readOnlyHint=false.

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 core purpose before the kind enumeration. The parentheticals earn their place by disambiguating kinds, though the prose is compressed enough that the kind-to-source mapping takes a moment to parse.

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 9 parameters, an output schema, and full schema coverage, the description needs to carry only the framing: what kinds exist and which sources are valid. It does that adequately; only the save side effect and the distinction from other plots.* tools are left 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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema's terse "Figure type: psd | topomap | bandpower | spectrogram" by explaining what each kind actually renders. It also groups the valid sources (MOABB packs, uploads, local files), adding meaning to the source parameter.

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+resource (render a figure over an EEG data source) and enumerates the four figure kinds with a parenthetical description of each, so an agent knows exactly what it produces. It identifies its non-plot sibling (data.inspect_dataset) as its companion, though it does not distinguish itself from the other plots.* 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 visual companion to data.inspect_dataset" and "sources are the same ones inspect uses" imply when to reach for it versus inspection, but there is no explicit when-to-use/when-not, and nothing routes the agent between plots.dataset, plots.erp, plots.confusion, and plots.leaderboard. Usage is implied rather than 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?

Annotations already declare idempotentHint=true, destructiveHint=false, openWorldHint=true, and readOnlyHint=false, so the safety and idempotency profile is mostly covered. The description adds useful context about the figure's content and its pre-training diagnostic purpose, but does not disclose additional behavioral traits such as save behavior, authentication needs, or rate limits.

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 two tight sentences with no wasted words. It front-loads the plot type and data source, then immediately gives the diagnostic purpose, making it easy to parse quickly.

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 need not be explained. Combined with 100% schema description coverage and annotations covering safety traits, the description provides enough context for an agent to understand the tool's purpose. It could be richer by noting the source variants or save option, but those are adequately captured in the schema.

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 100%, meaning all seven parameters are already documented in the schema. The description does not add any parameter-level meaning, which is acceptable but not value-adding; the baseline of 3 applies when schema coverage is high.

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: it creates an ERP butterfly figure from epoched data, detailing the subplot structure, channel means, and time-locking. It is clear what the tool does, but it does not explicitly distinguish itself from sibling plotting tools such as plots.dataset or plots.confusion.

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 states a clear use context: to inspect whether class-conditioned evoked structure exists BEFORE training anything. It does not name alternatives or say when not to use this tool, so it falls short of the explicit routing found in the top-scoring examples.

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?

Annotations already declare openWorldHint=true, idempotentHint=true and destructiveHint=false, and the description adds rendering behavior (distinct color for BYO submissions, muted LOSO side panel on pretrained_few_trial) that helps the agent anticipate the output. It does not, however, note that save=true writes a PNG to disk (only the schema says so), which is the one non-read-only behavior implied by readOnlyHint=false.

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?

Three sentences, front-loaded with the core deliverable (chart type, metric, ordering) before the companion/sibling note and the track caveat. Slightly wordy around the pretrained_few_trial clause but nothing is wasted.

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, the description needn't explain return values, and it adequately conveys what the figure shows and how track changes it. The only gap is acknowledging the save-to-disk side effect, which the schema covers instead.

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 100%, so all three parameters are already documented, and the description's note about the pretrained_few_trial side panel largely duplicates the track parameter's own schema text. Baseline 3 is correct when structured fields carry the parameter detail.

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?

Names a specific artifact (leaderboard bar chart for one dataset) with concrete visual details (accuracy with 95% CI whiskers, best first, BYO submissions highlighted), and explicitly positions itself as 'the visual companion to catalog.leaderboard', distinguishing it from that sibling and other plots.* tools.

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 'visual companion to catalog.leaderboard' implies when to reach for this tool versus fetching leaderboard data, and the track description explains context, but there is no explicit when/when-not guidance or statement of prerequisites for producing the figure.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds useful chaining context by noting it returns projectId, but says nothing about required permissions, whether name collisions are rejected, or side effects on servers. Modest added value against an already-covered annotation set.

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 terse sentences with zero waste; the core action leads and the return value follows. Every clause carries 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 two-parameter create tool with full schema coverage, annotations, and an output schema, the definition covers the essentials. The projectId mention is slightly redundant with the output schema, and the absence of any prerequisite or duplicate-name note is the only 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 description coverage is 100% for both parameters, so the schema already documents name (with an example) and description. The description contributes only the 'container for one pipeline document' framing and adds no syntax, format, or constraint detail beyond the schema. Baseline 3 applies.

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 ('Create a project') and goes further by defining what a project is ('container for one pipeline document') plus a return value. It clearly differs from sibling verbs like project.list, project.load, and project.save, though it doesn't name them 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?

No when-to-use guidance, no prerequisites, and no mention of the alternative project operations (list/load/save) that an agent might confuse this with. The create action is largely self-evident, which keeps this above a 1, but nothing is offered about sequencing or preconditions.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds real value beyond that: it specifies the blast radius (project plus saved pipeline document), the effect on the user's project list, and explicitly that already-run executions are unaffected. It doesn't cover auth/permission requirements, which would be needed for a 5.

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?

Three short sentences with the destructive action front-loaded, then the hard prerequisite, then the consequence note and id source. Every sentence carries information; nothing is padding.

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 need not be described. The description covers the destructive scope, the confirm gate, the non-effect on prior executions, and where to get the id — everything an agent needs before invoking an irreversible delete.

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 100%, so both parameters are already documented, including the confirm guard ('MUST be true to delete'). The description's 'Requires confirm=True' and 'Find ids with project.list' restate rather than extend the schema, so the baseline 3 is appropriate.

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 ('Delete a project') plus the scope of what is deleted ('and its saved pipeline document') and the location ('from the studio workspace'). This clearly differentiates it from sibling project.create/project.list/project.load/project.save without the agent needing to open any schema.

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 an explicit prerequisite ('Requires confirm=True') and routes the agent to project.list for obtaining ids, which is genuine when-to-use guidance. It stops short of naming when *not* to use it or an alternative deletion path, so it falls short of a 5.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the useful scoping constraint that results are limited to projects 'owned by the current principal (agent work included)', but says nothing about pagination, limits, or ordering.

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 tight sentence with the list action and its scope front-loaded; every clause carries information and nothing is wasted.

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 and annotations cover safety, so return values and risk profile are already documented. The description supplies the ownership scope, but leaves pagination/result-size behavior unaddressed, keeping it just short of fully complete.

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 the baseline is 4. There is nothing in the schema for the description to clarify further.

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 (list) and resource (projects) plus an ownership scope, and the verb alone separates it from project.create/load/save. It never names or contrasts those siblings explicitly, so it stops short of the top tier.

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 alternatives like project.load or project.create, and no prerequisites. Usage is only implied by the verb 'list'.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds only that the loaded document is the saved pipeline for editing/re-running; it says nothing about failure modes (unsaved project, missing pipeline), permissions, or whether the load is cached.

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 with zero filler; the resource and its payload are front-loaded before the purpose 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. For a single-parameter read tool this is nearly sufficient; only failure conditions and the relationship to project.save/pipeline.validate are 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 100% for the single project_id parameter, so the schema already carries the semantics. The description adds no format, id-shape, or lookup guidance beyond the schema, so baseline 3 applies.

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 (Load) and resource (a project's saved pipeline) and clarifies the payload as train graph + meta with the intent (editing/re-running). It is clear on its own, but it does not distinguish itself from adjacent siblings such as project.save or pipeline.export.

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 'for editing/re-running' implies the context in which to call it, but there is no explicit when-to-use versus alternatives (e.g., project.list to discover ids, pipeline.validate to check a loaded pipeline) and no stated prerequisites such as whether the project must already have been saved.

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?

Goes well beyond the annotations by disclosing optimistic-concurrency semantics: a mismatched revision 'fails with a conflict — it does NOT silently overwrite concurrent edits', and omission is rejected to prevent a stale single-writer path from wiping another client's work. The annotations only say non-readonly, non-idempotent, non-destructive; the description supplies the actual failure behavior an agent must anticipate.

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?

Front-loaded with the core action, then the critical revision contract; every sentence carries information. The parenthetical and em-dash clause are slightly wordy but earn their place by explaining why omission is rejected.

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 mutation tool with an output schema and full annotation coverage, the description supplies exactly the missing piece an agent needs — the concurrency contract and the failure mode — while return values are left to the output schema.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: where expected_revision should be sourced ('from the last project.load or a prior save/create response') and the consequence of a mismatch. It does not cover name/subject, but the schema already documents those.

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 ('Save a pipeline graph into a project') and adds the observable effect ('visible on the studio canvas'). It is clearly distinguishable from project.create, project.load, and project.delete in the sibling list.

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?

Explicitly says 'Always pass expected_revision from the last project.load (or a prior save/create response)', which gives the agent the required calling sequence relative to project.load/project.create. It stops short of stating when to choose save over create or what happens on the very first persist, so it is clear context rather than full when/when-not 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 annotations already covering the read-only/idempotent safety profile, the description adds substantive behavior: per-statistic minimum sample sizes (t/dz ≥ 3, Wilcoxon ≥ 5), a large base64 PNG return with guidance to render or save it, and a graceful empty-payload-instead-of-error contract that an agent needs to reason about output.

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 deliverable is front-loaded ('Paired pre/post analysis for one assignment') with details following. It is dense and clause-heavy with several parentheticals, but each clause conveys actionable information (minimums, figure format, empty-payload behavior) rather than 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?

For a tool that also has an output schema, the description is more than sufficient: it characterizes the payload contents, documents the statistical minimums, and explicitly resolves the empty-assignment case. Nothing an agent needs to invoke or interpret the call correctly 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?

Schema coverage is 100% and the single parameter is already documented in-schema ('from start_assignment'), so the schema carries the meaning. The description ties the analysis to 'one assignment' but adds no syntax or format detail beyond what the schema provides, matching the baseline for a fully documented single param.

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?

Names a specific analysis type (paired pre/post) scoped to one assignment's recorded sessions, and enumerates exactly what it produces (per-block aggregates, t/Wilcoxon/dz, trajectory, figure). The verb+resource is crystal clear, though it does not explicitly distinguish itself from the nearest sibling, stats.grouped.

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 intent (paired pre/post comparison for a single assignment) is implied by the content, and the edge case of an assignment with no recordings is noted, but there is no explicit 'use this when X, use stats.grouped when Y' routing guidance or prerequisites beyond the parameter's own note.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering safety. The description adds the scope of returned data (all saved protocol ids at latest version), but does not disclose pagination, ordering, or freshness beyond 'latest version'.

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 fragment. It is concise and contains no filler, though it is arguably too terse to be a complete sentence.

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 the tool is a parameterless list with an output schema, the description sufficiently states what is returned. The output schema likely details the return structure, so no further explanation is needed.

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 has zero parameters, so the description has no parameter semantics to cover. Baseline 4 applies.

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 the resource (saved protocol ids) and scope (every, at latest version), which is more specific than a generic 'list protocols'. However, it lacks an explicit verb and does not differentiate from siblings like protocol.session_status or protocol.export_stats, though the name helps.

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, prerequisites, or alternatives are provided. The description simply states the output; it does not guide the agent on when this is preferable to other protocol.* tools.

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?

Annotations already declare the safety profile (non-readOnly, non-destructive, open-world), so the description's added value is real: it discloses that recording blocks freeze, the session and device stay alive, and that simulated/playback sessions record no data while paused. It omits error behavior (pausing a non-running session) and any permission requirements.

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 carries the core action, with the parenthetical and trailing clause reserved for consequence detail. It is dense but every clause earns its place; slightly heavier punctuation than ideal for a one-parameter 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?

An output schema exists, so return values need no explanation, and the annotations cover safety. The description covers state effects and the resume path, but leaves precondition failure modes and required authorization unstated for a state-changing session 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?

There is a single parameter and schema description coverage is 100%, so the schema fully documents session_id on its own. The description adds nothing about the parameter (e.g. where to obtain the session_id or what happens with an invalid one), so the baseline 3 applies.

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 ('Pause a running protocol session') and immediately contrasts with the sibling that reverses it ('resume with protocol.resume'). An agent can distinguish this from protocol.stop and protocol.resume without opening any schema.

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?

It gives clear context for use (pausing a running session) and points to protocol.resume as the follow-up action, which is genuine routing guidance. It never states the inverse condition — e.g. when to prefer protocol.stop over pausing — so the 'when-not' half is left implicit.

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?

Annotations already give the safety profile (non-readonly, non-destructive, non-idempotent, open-world). The description adds value beyond them: the plan gating requirement and the fact that it restarts a server-driven loop, which is consistent with idempotentHint=false.

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?

Three short sentences, each carrying distinct information (action, gating, parameter hint), with the core action front-loaded. Tight and largely waste-free.

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 values need no explanation. The description covers the action, the gating condition, and the key parameter source, leaving little an agent needs 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 coverage is 100%, so the schema already documents all three params (baseline 3). The description adds meaningful guidance for n_channels by telling the agent where to obtain the value ('start_assignment reports it'), which the schema does not.

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 ('Resume a paused protocol session') and the core effect (restarts the server-driven device loop). It is clearly the inverse of protocol.pause, though it never names the sibling 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?

Implies the trigger condition (a paused session) and adds real constraints: live-hardware resume needs a Pro plan while simulated sessions are free. No explicit when-not guidance or named alternative, but context is clear.

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?

Annotations already declare non-readonly, non-idempotent, non-destructive, open-world, so the safety surface is partially covered. The description adds genuinely new behavioral detail: every call appends a version row (why non-idempotent matters), the confirm gate is mandatory, and edits create a new version that the assignment then pins. Auth requirements are still unstated, keeping it short of a 5.

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?

Front-loaded with the core action, then two compact parentheticals that supply the confirm gate and versioning model with no filler. Slightly dense, 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?

With a 100% coverage schema, a mandatory confirm flag, and an output schema already present, the description only needs to supply the behavioral side effects, which it does (append-per-call, version creation, assignment pinning). Nothing critical for a correct invocation is missing, though permission/error expectations are left 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 coverage is 100% and both parameters carry their own descriptions ('MUST be true to write', wire-format spec), so the schema does the heavy lifting per the baseline rule. The description reinforces the confirm semantics and the version-append consequence of calling, but adds no syntax or format detail 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 specific verb pair (validate and persist) with a precise scope (the NEXT VERSION of a protocol document), which cleanly separates it from the validate-only sibling protocol.validate. An agent can tell it is the write path of the protocol lifecycle without opening any schema.

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 confirm-gating note ('accidental calls clutter the version history') implies that this is the committing write step, but the description never names an alternative or states when to prefer protocol.validate instead. Usage is inferred rather than spelled out, so it lands at minimum-viable.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the snapshot is 'live' and enumerates the two payload halves, but says nothing about freshness guarantees, cost, or what happens for a stopped/finished session. With annotations carrying the safety burden, this is adequate but 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?

A single front-loaded sentence with no filler and no redundancy. It is slightly jargon-dense (the 'under ``protocol``' aside is cryptic without the output schema), but nothing is wasted.

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, the description need not explain return values, and annotations cover safety, so the remaining gap is routing: among ~50 siblings, several are status/report tools and the description gives no cue for choosing this one. Adequate but incomplete for a session-scoped inspector.

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 100%: window (1-200, default 50) and session_id (from start_assignment) are both fully documented in the schema. The description adds no format, default, or sourcing detail beyond that, so the baseline 3 applies.

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 resource and verb: a live snapshot of a protocol deploy session, enumerating the scheduler block, progress/threshold state, and telemetry window. It is clear what the tool returns, but it never distinguishes itself from adjacent status/reporting siblings such as protocol.list, calibration.status, or stream.status.

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