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

With no annotations, the description carries the full burden, and it does disclose the real behavioral trait that termination is via SIGTERM (an abrupt signal, not a graceful drain). However, it omits whether the job is marked failed/cancelled, whether partial output in output_dir is retained or removed, whether the operation is idempotent, and what permissions are required — significant gaps for a destructive mutation.

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

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

A single front-loaded sentence with the action, target, and mechanism; no filler or redundant restatement of the 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 values need not be explained, but for an unannotated destructive tool with two undocumented required parameters the definition is too thin. It should cover the effect on the job record and on files in output_dir, and irreversibility/idempotency.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. 'job_id' is only obliquely implied by 'a running job', and 'output_dir' — a required parameter on a cancel operation — is completely unexplained, leaving the agent to guess why a cancellation needs an output directory.

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

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

The description names a specific verb and resource ('Cancel a running job') and adds the mechanism ('sending SIGTERM to its process'), which clearly separates it from read-only siblings like get_job_status and list_jobs. It does not explicitly name a sibling or state that it is the only mutating counterpart to start_* tools, so it stops 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?

Usage is only implied by the qualifier 'running' — an agent can infer that the job must be active for this to apply. There is no explicit statement of when to use this versus purge_subject/prune_failed_subjects for cleanup, and no note on what happens if the job has already 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?

No annotations are provided, so the description carries the full burden. 'Retrieve' implies a read-only operation, but nothing is said about permissions, behavior for still-running jobs, truncation semantics beyond the tail window, or errors when a job/log does not exist.

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, appropriate for a simple retrieval tool. It is efficient, though it is terse to the point that useful detail was omitted rather than trimmed.

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, but with zero annotation coverage, zero schema descriptions, and one required parameter (output_dir) never addressed, the definition is not complete enough for an agent to call it confidently.

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

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

Schema description coverage is 0% across 3 parameters. The phrase 'last N lines' loosely maps to tail_lines and 'a job's log' implies job_id, but output_dir — a required parameter with no schema description — is entirely unexplained, leaving the agent to guess why a log read needs an output directory.

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 (retrieve) and resource (job's log output) and adds scope (last N lines), which cleanly separates it from siblings like get_job_status, list_jobs, and cancel_job. It does not explicitly name an alternative, but the resource is unambiguous enough that no sibling confusion arises.

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

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

No guidance on when to use this versus get_job_status or list_jobs, and no mention of prerequisites or when the log would be unavailable. The agent must infer that this is the diagnostic follow-up to a status check.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation via 'Get' but does not state read-only safety, auth requirements, rate limits, or that it will not modify or cancel the job.

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 wasted words. It is appropriately concise, though slightly terse given the required parameters and sibling alternatives.

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 covers return values, but with no annotations and zero parameter descriptions, the description should compensate by explaining output_dir and distinguishing this from list_jobs/get_job_log. It does neither.

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

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

Schema description coverage is 0%, and the description mentions neither job_id nor output_dir. An agent must infer job_id from the word 'job,' and output_dir is completely unexplained.

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

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

States a specific verb ('Get') and resource ('status and progress') scoped to a 'running or completed job.' It implicitly distinguishes from list_jobs and get_job_log but does not name those siblings 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 guidance on when to use this tool versus list_jobs, get_job_log, or cancel_job, and no prerequisites such as where job_id or output_dir come from. The only hint is the phrase 'running or completed job,' which implies a single-job context.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it adds nothing beyond restating the purpose. It does not clarify that this is a zero-side-effect read/introspection call, nor what kind of metadata or tool enumeration is returned; the only hint of behavior is the phrase 'available MCP tools'.

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. The resource and scope are stated immediately and nothing requires trimming.

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 zero-parameter introspection tool with an output schema already covering return values, the description is nearly sufficient. What is missing is the invocation context (when in an agent's workflow this discovery call is appropriate).

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 no parameters, so there is no parameter semantics to document; the 4 baseline applies. The description correctly does not fabricate inputs.

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 ('Get') and resource ('metadata about the Champollion pipeline and available MCP tools'), which is more than a restatement of the name. It is distinguishable from the start_* siblings and job-management siblings, though it never explicitly contrasts itself with get_job_status or list_jobs.

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 guidance on when to call this versus alternatives. Nothing tells the agent whether this should be invoked at the start of a session, when a pipeline name is unknown, or how it relates to get_job_status and list_jobs in the sibling set.

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

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

With no annotations, the description carries the full behavioral burden and mostly fails it: it says 'List all jobs' while the schema caps results at a default limit of 50, so the description arguably misleads about completeness. Nothing about pagination, result ordering, permissions, or truncation is disclosed.

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 the required parameter's role comes before the optional filter. It is efficiently sized for what it attempts, though efficiency here partly reflects under-specification.

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. However, for a 3-parameter list tool with no annotations and 0% schema description coverage, the missing limit/pagination behavior leaves a real gap in what 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 description coverage is 0%, so the description must compensate. It does explain output_dir and the status filter, but says nothing about the limit parameter and its default of 50 — an omission that matters because it directly contradicts the 'all jobs' framing.

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 all jobs') plus its scope ('for a given output directory'), which is enough to separate it from get_job_status and get_job_log. It does not, however, explicitly name or contrast those siblings, so it stops 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 phrase 'optionally filtered by status' hints at a use case but gives no when-to-use criteria and never mentions the obvious alternatives (get_job_status, get_job_log) that an agent must choose between in this crowded job-related sibling set. No exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden but only states what is checked, not how the tool behaves. It does not say whether it is read-only, whether it has side effects, or whether a failure raises an error versus reporting a status.

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 well-formed sentence with the purpose front-loaded and nothing extraneous. No filler or restatement of the tool name.

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

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

An output schema exists, so return values need not be explained in prose, and there are no parameters to document. For a simple zero-arg diagnostic the description is nearly sufficient, with only the missing usage cue and behavioral note as gaps.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for an empty parameter surface.

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 (check) and a specific resource (the Champollion pipeline's configuration and accessibility), making the diagnostic intent clear. It does not explicitly contrast itself with the sibling start_* or job tools, but the 'preflight' framing is self-evident enough to distinguish 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?

The description gives no when/when-not guidance and never mentions the alternatives (e.g. start_pipeline or get_pipeline_info). An agent must infer that this is a pre-run validation step rather than something to be told.

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

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

With no annotations, the description carries the full burden and does well: it discloses exactly what gets deleted (all files for failing subjects), the exact selection rule, and adds a dry_run safety preview. It stops short of stating that deletion is irreversible or whether any confirmation/permissions are required.

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 destructive action, then the selection semantics, then the safety escape hatch. No filler sentences; every line earns its place.

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

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

An output schema exists so return values need not be explained, and the description covers the destructive semantics and QC input format. The only real gap is the unexplained required 'output' parameter and the absence of an irreversibility warning for a file-deleting 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 coverage is 0%, so the description must compensate. It explains the qc parameter well (TSV/CSV with 'participant_id' and 'qc' columns) and dry_run's preview role, but the required 'output' parameter is never described anywhere in the definition.

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 ('Remove') and resource ('cortical_tiles outputs') with clear scope ('for all subjects that failed QC'). The 'all subjects' scope implicitly distinguishes it from the singular purge_subject sibling, so an agent can route correctly.

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 defines the selection criteria clearly (qc==0 or absent from QC file) and tells the agent to use dry_run=True to preview. However, it never names an alternative tool or states exclusion conditions, so the when-to-use guidance is implied 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?

With no annotations provided, the description carries the full burden and does well: it discloses precisely what is destroyed (NIfTI files, subdirectories, and rows filtered from aggregated .npy arrays and CSVs), which is the key destructive-scope information an agent needs. It stops short of stating irreversibility, required permissions, or preconditions, which keeps it from 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, followed by a justified enumeration of affected artifacts and a short dry_run tip. The middle sentence is a dense list, but every item earns its place by telling the agent what will be lost.

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 the description covers the destructive footprint thoroughly for a no-annotation tool. It is still missing irreversibility and preconditions, which matter for an unrecoverable deletion operation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains dry_run semantics well ('preview what would be deleted without modifying anything') and implies subject is a single subject identifier, but never clarifies what the required 'derivatives' parameter expects (a path, an output root, a config name), leaving a required parameter ambiguous.

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 opens with a specific verb and resource scoped to a single subject ('Remove all cortical_tiles derivatives for a single subject') and then enumerates exactly which artifacts are targeted. This distinguishes it cleanly from siblings like prune_failed_subjects or cancel_job without 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?

Usage context is implied (per-subject cleanup of derivative outputs) and the dry_run preview workflow is explicitly recommended, which is genuinely useful. However, the description never states when to choose this over the sibling prune_failed_subjects, nor any prerequisite such as stopping the pipeline before purging.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says 'Launch' but does not disclose whether this is async and returns a job handle (siblings like get_job_status/list_jobs/cancel_job hint at a job model), whether it overwrites an existing output directory, or what permissions/inputs must already exist. For a launch/mutation tool with zero annotation coverage this is a real gap.

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 action front-loaded and no filler; every clause carries information. It is efficient, though so terse that the omitted context is conspicuous.

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?

Although an output schema exists (so return values need not be described), this is a pipeline-launching mutation tool with no annotations and 0% parameter documentation. The description omits prerequisites, job semantics, and parameter expectations, leaving an agent unable to invoke it confidently from the definition alone.

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

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

Schema description coverage is 0% and both parameters (embeddings_source, output_path) are undocumented in the schema. The description only loosely implies them ('per-region embedding CSVs' for embeddings_source, 'output directory' for output_path); it never states expected path formats, whether embeddings_source is a directory or list, or that output_path must be writable.

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 action (launch the Stage 5 combine) and the concrete effect (collecting per-region embedding CSVs into one output directory). This differentiates it from start_embeddings or start_morphologist, but it never names or contrasts a sibling explicitly, so it stops 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 'Stage 5' label implies this runs after the embeddings stage, which is useful sequencing context. However, there is no explicit when-to-use/when-not guidance, no statement of prerequisites (e.g., all regions must have completed embeddings), and no routing to alternatives such as start_embeddings or a full start_pipeline.

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

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

With no annotations, the description carries the full burden and does add real behavioral detail: default configs-root derivation, that output/external_config are forwarded only when supplied, and that they must be absolute paths inside a declared root. However, it never says whether existing configs are overwritten, what permissions are required, or what the launch actually produces/schedules.

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 tightly packed defaults and constraint details. Dense but each clause carries information; no filler or restatement of the name.

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

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

An output schema exists, so return values need not be described, and the path/default semantics are well covered. But for a launch tool with 0% schema coverage and no annotations, the omission of external_crops and champollion_loc and the lack of any statement about overwrite/ordering behavior leaves gaps.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It explains output, external_config, masks, and the crop_path/dataset root derivation well, but external_crops and champollion_loc are left completely undocumented, leaving two parameters with no meaning anywhere.

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

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

States a concrete verb and scope: 'Launch Stage 3: generate Champollion dataset YAML configuration files.' The stage number distinguishes it from the sibling start_* pipeline stages (morphologist, cortical_tiles, etc.), though it never names an alternative explicitly.

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

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

Usage context is only implied by the 'Stage 3' framing and the note that 'masks ... must match the stage-2 masks,' which is a prerequisite for correct use. There is no statement of when to call this versus start_pipeline or the other start_* tools, and no exclusion guidance.

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

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

With no annotations, the description carries the full behavioral burden, yet it only says the job is 'launched'. It does not disclose that this is a long-running/async job, whether a job id is returned, what overwrite does to existing outputs, or any resource/parallelism behavior implied by njobs.

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 or repetition; every word carries information. It is terse rather than padded, so the shortfall is under-specification captured in other dimensions, not verbosity.

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 10-parameter pipeline-stage launcher with zero annotation coverage, the description omits prerequisites, stage sequencing, and parameter meaning. The existence of an output schema excuses it from documenting return values, but little else is covered.

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 are 10 parameters at 0% schema description coverage, and the description explains none of them. 'Extract 28 sulcal region crops' faintly gestures at the regions parameter but leaves input_dir, output_dir, path_to_graph, path_sk_with_hull, masks, njobs, overwrite, sk_qc_path, and labelling_session entirely undefined.

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 ('Launch'), a stage ('Stage 2'), and a concrete resource ('28 sulcal region crops with cortical_tiles'), so the agent knows it kicks off a tile-extraction stage rather than a generic pipeline run. It does not, however, explicitly distinguish itself from the other start_* siblings beyond the 'Stage 2' label.

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 (e.g. that Stage 1 must have produced path_to_graph / path_sk_with_hull), and no mention of alternatives such as start_pipeline or start_morphologist. The agent must infer ordering entirely from the stage number.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the semantics of four behavior-changing flags (profiling, no_cache, legacy, use_last_checkpoint), which is real value, but it omits key traits for a compute job: that it is long-running, that it writes embeddings to disk, and whether existing outputs are overwritten.

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 lead sentence front-loads the purpose and scope, followed by terse one-line flag definitions. Structure is good and there is little waste, though the flag block could be better tied to the parameter names an agent must supply.

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 15-parameter, no-annotation tool with 0% schema coverage, the description is thin: it omits prerequisites, expected runtime/compute implications, output locations, and most parameter meanings. An output schema exists, so return values need not be explained, but the invocation-side gaps are significant.

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

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

Schema description coverage is 0% across 15 parameters, so the description must compensate and only partially does. It explains profiling, no_cache, legacy, and use_last_checkpoint, but leaves 11 parameters undocumented, including the required models_path and datasets_root and the meaning of cpu, output, regions, subjects, masks_version, and cortical_version.

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 and resource ('compute sulcal embeddings') and pins down scope ('across all 56 model folds (28 regions x 2 hemispheres)') plus its place in the pipeline ('Stage 4'). It does not explicitly contrast itself with siblings like start_training or start_cortical_tiles, so it falls short of full differentiation.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the alternatives in the sibling set. The only implied context is the 'Stage 4' label, which hints at pipeline ordering but does not state prerequisites (e.g., that models must already be trained) or how it relates to start_pipeline.

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

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

No annotations, so the description carries full behavioral burden, but it only says what will be generated and from what data. It does not disclose whether the launch is synchronous or asynchronous, what directories must pre-exist, permissions, or side effects; output schema covers return shape but not execution behavior.

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

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

The single sentence is front-loaded with the verb and stage, and contains no wasted words. However, for a four-parameter pipeline stage with no schema documentation, it is too thin to be considered appropriately sized, so it earns only a middling score.

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

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

Given no annotations, zero parameter documentation, and a multi-stage sibling suite, the description is not complete enough to guide correct invocation. The presence of an output schema removes the need to describe return values, but input preparation, execution mode, and stage relationships remain 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 0% for four parameters, so the description must compensate, yet it only vaguely references 'raw T1 MRI data' and says nothing about input_dir, output_dir, parallel, or enable_sulcal_recognition. An agent cannot infer the meaning or required format of any parameter from the 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?

States a specific verb 'Launch' and resource 'sulcal graphs with Morphologist from raw T1 MRI data,' and identifies the pipeline stage ('Stage 1'). It implicitly distinguishes itself from later start_* siblings, but does not name an alternative or explicitly state what it is not for, so it stops short of 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?

Provides no when-to-use or when-not-to-use guidance relative to the many start_* siblings. It does not mention prerequisites such as preflight_check or how this stage relates to downstream stages, leaving the agent to infer usage from the stage number alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses async behavior ("Returns a pipeline job_id immediately") and which stages read/write the masks directory, but omits failure behavior, whether overwrite can destroy existing data, and how this job interacts with cancel_job/get_job_status.

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 purpose and return in the first sentence, then groups parameter behavior by stage. Dense but earned for a 21-parameter tool; only minor tightening is possible.

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 the job_id is still noted. However, for a 21-parameter, zero-coverage, no-annotation mutation tool, the description leaves too many required inputs and the skip_stages option undocumented to be considered 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?

Schema coverage is 0% across 21 parameters, so the description must compensate and only partially does. It adds real meaning for masks, reference_data_dir, overwrite, run_cka, regions, masks_version, and cortical_version, but leaves the 8 required paths plus cpu, njobs, parallel, skip_stages, and labelling_session entirely undefined — skip_stages in particular is never mentioned.

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 ("Launch the full Champollion pipeline"), quantifies scope ("all 6 stages sequentially"), and discloses the immediate return (job_id). It implicitly distinguishes itself from the stage-level siblings via "full" and "all 6 stages," but never names an alternative tool, so it stops 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?

Usage is implied rather than stated: the pipeline runs everything, so an agent can infer the stage-level siblings (start_embeddings, start_snapshots, etc.) are for partial runs, but the description never says when to prefer start_pipeline over them. No prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that reference_data_dir is not shipped with champollion_pipeline and has no default, but it omits anything about job lifecycle (is this async? does it return a job id?), overwrite/re-run behavior, and expected runtime for a 'render' stage.

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 stage number and outputs before the gotcha about reference_data_dir. Every sentence earns its place, though the backtick/line-break formatting is a little awkward for an agent-facing string.

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

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

An output schema exists so return values needn't be described, but for a 12-parameter job-launching tool with no annotations and 0% schema coverage, the description covers only the entry point and one dependency. An agent cannot confidently map most inputs or know whether this is blocking or background work.

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

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

Schema description coverage is 0% across 12 parameters, so the description must compensate. It explains only embeddings_dir and reference_data_dir, leaving output_dir (the sole required param), subject, acquisition, the *_only flags, umap_region, and the various *_dir inputs entirely undocumented in both schema and prose.

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 ('Launch') and a precise resource set framed as 'Stage 6: render sulcal graph meshes, cortical tile masks, and UMAP scatter plots', which clearly separates it from siblings like start_cortical_tiles and start_embeddings. It is specific about what gets produced, though it never explicitly names the alternative stages an agent might confuse it with.

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 'Stage 6' framing implies that earlier stages must run first, and the UMAP precondition ('needs both embeddings_dir and reference_data_dir') is actionable guidance. However, there is no explicit when-to-use/when-not statement, no mention of start_pipeline as an alternative, and no note on whether it can be re-run or resumed.

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

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

With no annotations, the description carries the full burden. It does disclose useful behavior: the config prerequisite and the exact default-resolution rules for config_dir/output_dir across roots vs pipeline modes. It is silent, though, on overwrite semantics, whether training is async/job-backed (relevant given get_job_status/list_jobs siblings), and resource/permission expectations.

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

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

The purpose is correctly front-loaded in the first sentence, and the prerequisite follows logically. The remainder is a dense, repetitive paragraph dedicated almost entirely to config_dir path resolution while the other seven parameters get nothing, which is an imbalanced use of space.

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. But for a 9-parameter, annotation-free tool, leaving cpu, swf, mode, njobs, and overwrite entirely unexplained is a material gap an agent needs to invoke it correctly.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. It thoroughly explains config_dir (and indirectly output_dir), but cpu, swf, mode, njobs, and overwrite receive no explanation at all, leaving the majority of parameters undocumented in both schema and 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 gives a specific verb (launch/train), a concrete resource (champollion_V1 self-supervised encoder), and a clear scope (one sulcal region), so an agent can distinguish it from start_config or start_embeddings. It does not explicitly name a sibling to differentiate from, which keeps it below 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?

It states a strong prerequisite ('Dataset configs must exist before calling this tool: run start_config first'), which is genuine ordering guidance. However, it never says when to choose this over alternatives like start_embeddings or start_pipeline, so the when-vs-alternatives dimension is only implied.

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