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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that the call spans machine-level state (GPU VRAM/load, queues, active jobs) rather than one resource, which is useful scoping context. However, since an output schema exists, listing the reported sections largely restates the return payload, and no latency, auth, or freshness behavior 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 opens with the core purpose ('Connection check and machine overview') before the enumeration. No filler, no 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?

For a zero-parameter read-only tool with an output schema and readOnly/openWorld annotations, the description supplies enough to call it correctly. The only gap is guidance on when in a workflow to invoke it, which matters given the surrounding job-orchestration siblings.

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. The description correctly implies a single parameterless call returning a full snapshot.

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 says specifically that this is a connection check plus machine overview, and enumerates the reported sections (GPUs with VRAM and load, queues, active jobs, data folders). That distinguishes it well from every sibling, all of which operate on a single job, dataset, or captions resource. It stops short of an explicit statement that nothing is mutated or filtered, 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?

Usage is only implied: 'Connection check' hints at a diagnostic call to make before or instead of job operations, but the description never says when to call it, whether to call it first, or what to do if it fails. No sibling is named as an alternative or follow-up. An agent can infer it is a preflight/overview call but must guess at that.

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?

Beyond the annotations, the description discloses important behavioral traits: it uses GPU time, downloads the captioner model on first use, captions only uncaptioned files by default, uses different default prompts for image-only versus video/audio datasets, and can be tracked with get_job. These details materially help an agent understand cost, side effects, and follow-up actions.

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 compact and front-loaded: it starts with the action, then immediately clarifies default captioning scope, prompt behavior, resource cost, and job tracking. Every sentence adds useful information without repetition.

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

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

The tool queues a GPU job and the description covers the most important operational context: cost, model download, default captioning behavior, prompt override, and tracking via get_job. An output schema exists, so return values need not be explained, but the missing parameter details for gpu_ids and caption_ext keep it from being 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains recaption and prompt well, including default prompt behavior, but does not describe dataset format, gpu_ids, or caption_ext at all, leaving three of five parameters undocumented.

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

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

The description states a specific verb and resource: queue ai-toolkit's built-in captioning job for a dataset, naming Qwen3-Omni and comparing it to the UI's Caption button. This clearly distinguishes the tool from sibling operations like set_captions and get_captions by framing it as the automatic captioning-job trigger.

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 when to use the tool by explaining that it behaves like the UI Caption button and that it captions only uncaptioned files unless recaption is set. However, it does not explicitly compare against alternatives such as set_captions or explain when not to use this tool.

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 this is a non-read-only but non-destructive, closed-world write. The description adds genuinely useful behavior beyond that: paths resolve on the MCP host, folders are recursed, caption files are auto-paired, and transfer goes over the UI's API so it works cross-machine. It omits what happens on duplicate names or partial upload failures, 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?

Front-loaded with the action in the first clause, then supporting mechanics in a tight second paragraph. Efficient overall, though the backtick-only parameter mention without explanation costs a little clarity for little gain.

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, and the description adequately covers the mutation's mechanics and environment assumptions. The main remaining gap is the unexplained caption_ext parameter and duplicate-name behavior for a tool that can append to existing datasets.

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 carry parameter meaning. It does well for `paths` (files vs. folders, recursion, caption pairing), but `caption_ext` is never explained — the example 'photo1.txt' hints at the default only indirectly — and `name` is left undefined as to uniqueness or reuse 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?

States a specific verb and resource ('Create a dataset ... by uploading local files') and adds the important nuance that it can also append to an existing dataset. That distinguishes it from list_datasets, set_captions, and the job-creation siblings without needing 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?

Implicit usage is clear: call this when you need a dataset materialized from local files. However, it never states when to prefer a sibling (e.g., set_captions or auto_caption_dataset after creation) or what happens if the name collides with an existing dataset, so routing is left partly 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 cover the safety profile (readOnly=false, destructive=false, openWorld=false), so the description's job is added context, and it delivers: what happens when no config is supplied, that `base_job` clones an existing job's config, and that `overrides` mutates config.process[0]. It doesn't say whether creation validates the config, whether the job is written to disk, or what happens on invalid 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?

Front-loaded with the verb+resource, then organized by concern (config source, overrides, gpu, start) rather than as a wall of prose. Dense but every clause carries operational meaning; the only waste is a slightly awkward line break after the first 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?

This is a multi-parameter mutation tool, and the description covers selection logic, formatting, and the immediate-start flag. Since an output schema exists, return values need not be described, but the absence of any statement about validation, error behavior, or name uniqueness leaves a small 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 0%, so the description carries the full burden and does so well: `config` accepts YAML/JSON of a full file or just the `config:` body, `base_job` takes an id/name, `overrides` uses dotted paths with a concrete worked example, `gpu_ids` takes an index string like "0,1", and `start` queues immediately. Only the obvious `name` is left to the schema title.

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 training job in the ai-toolkit UI"), which is unambiguous. It does not explicitly differentiate itself from siblings like `new_job_template` or `start_job` — the default-template mention is the only hint at how it relates to those 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 explicit branching guidance for the mutually exclusive config sources ("pick one: config ... or base_job ...; Neither = the default template") and explains that `start` queues immediately, which implicitly answers when to use this versus a later `start_job`. It stops short of naming sibling alternatives or stating prerequisites/failure modes.

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 and openWorldHint=false, so safety and world scope are covered. The description adds useful behavioral detail that empty string means uncaptioned and that a missing-caption count is included, but it does not explain limit behavior, caption extension handling, or result 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?

The description is a single front-loaded sentence with no wasted words. The key output semantics are placed immediately, and the parenthetical detail is compact.

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, reducing the description's burden. However, with zero schema description coverage on three input parameters, the description should say more about limit and caption_ext to be 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?

Schema description coverage is 0%, so the description must compensate for all three parameters. It effectively clarifies the dataset parameter and caption meaning, but it says nothing about limit or caption_ext, leaving two parameters undocumented.

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

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

The description clearly states the resource being returned: captions for each file in a dataset, with empty strings indicating uncaptioned files. It distinguishes retrieval from mutation siblings like set_captions by saying captions are returned, but it does not explicitly contrast with auto_caption_dataset or set_captions.

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 this is for reading captions, but it gives no explicit when-to-use guidance, prerequisites, or alternative tools. It does not say when to prefer this over list_datasets, set_captions, or auto_caption_dataset.

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 and openWorldHint=false, so the safety profile is covered. The description adds only that the call returns status and progress, which is largely restating what the output schema provides; there is no note on staleness, polling cadence, or which job states exist for a running 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?

Two short sentences with the return content front-loaded and the parameter note second; no filler. It is terse to the point of being fragmentary, 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 needn't be explained, and a single required param is simple. Still, for a tool sitting among list_jobs, get_job_config, and get_job_log, the definition never positions itself in that family, leaving the agent to guess which call answers 'is my job done?'.

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

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

Schema description coverage is 0%, so the description must carry the parameter. It does add value by clarifying that 'job' accepts either an id or a name — something the bare string schema does not say — but gives no id format examples or hints on where to obtain one.

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 the resource ('one job') and what it returns ('status and progress'), which is a specific and greppable purpose. The phrase 'one job' implicitly separates it from the sibling list_jobs, though no sibling is named explicitly.

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

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

No guidance on when to use this versus the many adjacent siblings such as list_jobs, get_job_config, get_job_log, or get_loss. The agent must infer from the name alone that this is the summary-status call rather than a config, log, or metrics call.

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 and openWorldHint=false, so safety is covered. The description adds the useful disclosure that output is YAML rather than a structured object, but says nothing about failure behavior when the job is missing or how large a config can be.

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

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

Two short sentences, return format front-loaded, and zero redundant restatement of annotations or name. Nothing 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 and read-only annotations declared, the remaining burden is small, but the undefined identifier format for 'job' and the absence of any link to new_job_template leave a real gap for an agent composing a new run.

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

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

Schema coverage is 0% and the single 'job' parameter is undocumented in the schema, yet the description never says whether it expects a job ID, name, or slug. With low coverage the description is expected to compensate, and it 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 ('full training config of a job') and adds the return format (YAML), which cleanly separates it from get_job, get_job_log, and list_jobs. It stops short of naming a sibling explicitly, so it is clear but not actively differentiated.

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

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

'Useful as a starting point for a new run' implies a use case but gives no explicit when-to-use vs when-not, and does not point at new_job_template or create_job as the adjacent path. Usage is inferable 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 cover safety (readOnlyHint=true, openWorldHint=false); the description adds genuine behavioral value by disclosing that progress-bar noise is collapsed, which affects what the agent will actually see. It does not say what happens when the log is empty, truncated, or the job has not started.

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 returned resource and followed immediately by the one non-obvious behavior. 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?

The output schema exists, so return shape need not be explained, but with zero schema description coverage the description should still pin down the two input parameters. It leaves the agent guessing about the job identifier format and tail 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 0%, so the description must compensate and does not: it never clarifies whether `job` is an ID or a name, nor what `tail_lines` means or that it defaults to 60. 'Last lines' only loosely gestures at the tail 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 specific resource and scope: the last lines of a job's training log, plus a distinguishing trait (progress-bar noise collapsed). It is implicitly distinguishable from siblings like get_loss or get_job_config, but it never names them or explicitly draws the boundary.

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

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

No guidance on when to reach for this versus get_loss, get_job, or list_job_outputs, and no prerequisites such as whether the job must be running or have produced a log yet. The agent must infer all situational 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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful output context (first/last/min, smoothed trend, evenly spaced points) but does not disclose error behavior, pagination, or whether the job must 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?

The description is a single, front-loaded sentence with no filler. Every phrase contributes to the output summary being described.

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 fully explained, and annotations cover safety. Still, the description does not clarify the required job identifier or what 'key' controls, which matters for correct invocation.

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

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

Schema description coverage is 0% and the description does not explain the required 'job' parameter or the 'key' and 'max_points' parameters. 'Evenly spaced points' vaguely gestures at max_points, but the core parameter semantics are left to the bare 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?

The description names a specific resource and output type: a loss curve summary with first/last/min values, trend, and sampled points. It is clear what the tool returns, but it does not distinguish itself from siblings such as get_job_log or list_job_outputs.

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 by the phrase 'Loss curve summary' – an agent can infer it is used when a compact loss overview is needed. However, there is no explicit when-to-use guidance, no exclusions, and no mention of 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds that results carry full paths and file counts, which is real behavioral context. It doesn't discuss ordering, empty-state behavior, or recursion, but an output schema exists to carry return 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?

Two sentences, no filler. What it returns comes first, the actionable follow-up second, which matches the order an agent needs them.

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 no inputs, the description only needs to establish scope and the path-to-job linkage, and it does both. A note on whether nested folders are included or how results are ordered would close 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 there is nothing for the description to disambiguate at the argument level. Baseline 4 applies; the description correctly adds no phantom parameter language.

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 (list) and resource (dataset folders) scoped to ai-toolkit's datasets folder, and it names the returned fields (full paths and file counts). An agent can distinguish it from list_jobs, list_job_outputs, and create_dataset 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 second sentence gives concrete downstream usage: take the `path` value and use it as `datasets.0.folder_path` when creating a job. That ties the tool to the create_job workflow. It stops short of explicit when-not guidance, but for a zero-argument read-only lister there is little ambiguity to resolve.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by saying the outputs are checkpoint files and sample media returned as local paths, which helps the agent understand what kind of data comes back. It does not discuss job-state prerequisites or empty-output behavior, but that is a minor gap given 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 that front-loads the key output types and ends with the important 'local paths' detail. There is no filler or repetition.

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 one-parameter, read-only tool with an output schema and annotations, the description is mostly adequate because it explains what the returned files are. However, it leaves the 'job' parameter under-specified and gives no usage guidance relative to sibling job-inspection tools, so it is not 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?

Schema description coverage is 0% for the single required 'job' parameter, so the description must compensate and does not. It only repeats that outputs are produced by a job, without clarifying whether 'job' is an ID, name, path, or other identifier format.

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

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

The description states a specific resource more than the name alone: checkpoint .safetensors files and sample media produced by a job, returned as local paths. This distinguishes it from siblings like get_job_log or get_loss, though it does not explicitly name an alternative or use the verb '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?

There is no explicit guidance on when to use this tool versus list_jobs, get_job, get_job_config, or view_samples. Usage is only implied by the phrase 'produced by a job', leaving the agent to infer the selection criteria.

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 and openWorldHint=false, so safety and locality are covered. The description adds useful ordering context ('newest first') and the returned fields, but says nothing about pagination, limits, or how many jobs come back, leaving a real gap for a list tool.

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

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

A single tight sentence with the ordering detail front-loaded and no wasted words. Every element (resource, order, returned fields) 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 described, and the safety profile is covered by annotations. However, for a filtered-list tool the lone active_only parameter is undocumented in both schema and description, leaving the definition incomplete 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?

There is one parameter (active_only) with 0% schema description coverage, and the description never mentions it. The description must compensate for the empty schema here and does not, so an agent cannot learn from the definition what active_only filters on.

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 ('List training jobs') plus the ordering ('newest first') and the fields surfaced (status, progress, model). It implicitly contrasts with get_job by being a listing operation, though it never names that 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?

Usage is only implied by the verb 'List' — an agent can infer this is the enumeration tool versus get_job (single) or create_job (mutate), but there is no explicit when-to-use or when-not guidance and no mention of the alternative 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds context an agent needs: this is a starting template meant to be edited, not a finalized config, and its sibling guidance implies the model-specific tuning is the caller's job. Output schema exists, so no credit is needed for return format.

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 with zero filler; the primary purpose is front-loaded and the fallback guidance is demoted to a trailing clause. Nothing here restates 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?

For a no-arg, read-only generator with a declared output schema, the description covers everything an agent needs: what the YAML represents, which model it targets, and where to go when the default doesn't apply.

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 of 4 applies. The description correctly signals the tool is argument-free, as the interesting content comes back in the response rather than being configured on input.

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

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

The first sentence names the exact artifact returned: the UI's default job config (Flex.1 LoRA) serialized as YAML. It is immediately distinguishable from get_job_config (existing job's config) and create_job (the consumer of this output).

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 the positive path (edit this YAML and pass it to create_job) and an explicit alternative for cases it does not fit: clone a previous job via create_job(base_job=...) for other models, or read config/examples/*.yaml. That is a concrete when/when-not with 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 cover safety profile (readOnlyHint=false, destructiveHint=false), so the bar is lower, and the description still adds the key behavioral fact: existing captions for the named files are replaced. That overwrite semantics is precisely the kind of thing an agent needs and is not derivable from annotations. It stops short of saying whether unlisted files are left untouched or whether a partial map is atomic.

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, no filler, with the action first and the overwrite warning attached to the parameter it concerns. Nothing could be cut without losing 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?

An output schema exists so return values need no explanation, but with three undocumented parameters and a mutation that overwrites data, the description should say what `caption_ext` controls and what happens to files not listed in the map. Adequate but leaves the agent guessing on edge cases.

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 carry the load, and it does well for `captions` by explaining the key/value meaning and cross-referencing get_captions' file names. `dataset` and especially `caption_ext` (default "txt") are left entirely unexplained, which is a real gap for a 3-parameter mutation.

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 ("Write captions") and it immediately clarifies the shape of the write via the `captions` map keyed by file name. The get_captions back-reference makes the read/write pairing with its sibling clear without naming it explicitly as an alternative.

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 mention of `get_captions` suggests the read-then-write workflow, and "existing captions ... are replaced" hints at the risk of overwriting. There is no explicit statement of when to use this versus auto_caption_dataset, which is the obvious competing sibling for producing captions.

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 that this is a non-read-only, non-destructive, closed-world operation. The description adds useful behavioral context beyond that: it queues the job, starts its GPU queue, and resumes from the last checkpoint when available.

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 tightly written sentences with the primary action front-loaded and no wasted text. The checkpoint-resume condition is concise and useful.

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. However, the description omits important context such as the expected job identifier and whether a job must already exist or be created via create_job first.

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 the sole required parameter 'job', and the description only mentions 'a job' without clarifying whether this is a job ID, name, or other identifier. It does not compensate for the missing parameter documentation.

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 uses specific verbs ('Queue', 'start') and resources ('job', 'GPU queue') and states the resume-from-checkpoint behavior. It is clear on its own, but does not explicitly distinguish itself from siblings like create_job or trigger.

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 by 'Queue a job and start its GPU queue' and the checkpoint-resume note, but there is no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as create_job or trigger.

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 and readOnlyHint=false, but the description adds the crucial nuance that a normal stop persists a checkpoint while force kills the process immediately, which changes the data-loss calculus. It still doesn't say whether a stopped job can be resumed from that checkpoint or what permissions are needed.

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, the default behavior front-loaded and the escalation path second. 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 no explanation, and the destructive semantics plus the graceful/force tradeoff are covered. The remaining gap is identifying what `job` should contain, which an agent must guess before it can call the 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 carry parameter meaning; it does an excellent job on `force` (what it does, when it is appropriate) but says nothing about `job` — no hint whether it takes an ID, name, or the value returned by list_jobs/create_job. Partial compensation for a zero-coverage schema lands at 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+resource ('Stop a job') and immediately qualifies the mode ('gracefully, saves a checkpoint first'), so an agent can tell it apart from start_job and from a hard kill. It does not name any sibling explicitly, which keeps it just shy 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?

Gives a concrete condition for the risky path: force is 'only for jobs stuck and ignoring a normal stop,' which is an explicit when-not guidance and steers the agent to the default first. No mention of checking get_job/get_job_log before stopping, so the alternative-routing is incomplete but the primary usage rule 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 readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds useful asynchronous timing context ('on its next step') and the requirement that the job be running, but it does not explain whether repeated triggers queue, whether checkpoint saving overwrites existing state, or what happens if the job is not running.

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 states the action and timing 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?

An output schema exists, so return-value explanation is not needed, and annotations cover the safety profile. Still, for a trigger tool, the description omits edge-case behavior such as what happens if the job is not running or whether multiple triggers interact.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It maps the enum values well by explaining that 'save' produces a checkpoint and 'sample' generates samples, but it leaves the 'job' parameter only implicitly defined as a running job identifier.

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 effect: asking a running job to save a checkpoint or generate samples on its next step. It is clear what the tool does, though the generic name 'trigger' and lack of explicit sibling differentiation keep it from 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 'running job' and 'next step' imply when to use it, but there is no explicit when-not guidance or reference to alternatives like start_job or stop_job. Usage is inferable 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 readOnlyHint=false, destructiveHint=false, and openWorldHint=false; the description adds the genuinely useful precondition that the job must not be running and that overrides are scoped to config.process[0]. It does not explain error behavior when the job is running or how unspecified config fields are treated, but that is a modest gap given the annotation coverage.

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

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

A single dense sentence with no filler, and the precondition is front-loaded before the mechanics. The backtick notation and parenthetical are slightly compressed for a first read but earn their 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 needn't be described, and annotations cover the safety profile. Still, for a mutation tool with four parameters at 0% schema coverage, the unmentioned `gpu_ids` field and the absence of any failure-mode guidance leave the definition only partially 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%, so the description must carry the load: it clarifies that `config` is YAML/JSON and that `overrides` are dotted paths inside config.process[0], matching create_job. However `job` and especially `gpu_ids` are never mentioned, leaving a meaningful gap for a 4-parameter tool.

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 (edit) plus resource (job) and narrows scope to 'a job that isn't running', which cleanly separates it from start_job, stop_job, and create_job in the sibling list. It also names the two edit modes (config replacement vs. dotted-path overrides), so the agent knows exactly what the tool mutates.

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 precondition (only jobs that aren't running) and points to create_job as the reference format for overrides. It does not spell out when to prefer a full config replacement over overrides, or what to do if the job is running, so it falls short of 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?

Annotations already establish this as a safe read-only operation on closed data, so the safety profile is covered. The description adds that only the *most recent* samples are returned, which is useful scoping, but says nothing about image format, where samples come from, whether older samples are retrievable, or latency/size concerns.

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 that front-loads the action and resource, with the motivation trailing. Nothing extraneous and nothing 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?

There is no output schema, so the description could have said what comes back (file paths, URLs, inline images) and how many by default. It's minimally viable for a simple read tool, but with 0% parameter coverage it should do more work than it does.

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 carry parameter meaning and it largely doesn't. "job" is only obliquely implied, and the key "count" parameter (default 4) is never explained — no statement of what it controls, its valid range, or the maximum allowed.

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 and resource ("Return the most recent sample images from a job") plus a stated purpose ("judge training progress visually"). That purpose implicitly separates it from siblings like get_loss and get_job_log, though no sibling is named explicitly.

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

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

The phrase "so you can judge training progress visually" implies the use case and distinguishes it from numerical loss or log inspection. However, it offers no explicit when-not guidance, no mention of alternatives such as get_loss or list_job_outputs, and no prerequisites.

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