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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Always returns instantly' and defines exactly what it returns: 'list of all checkpoints and any new ones.' It also explains the diff semantics for known_checkpoints. While it doesn't explicitly say there are no side effects, the 'check' framing and instant-return statement make the read-only nature reasonably clear.

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, with the core purpose and the 'Always returns instantly' behavior stated in the first sentence. The argument list is minimal, directly mapped to the schema, and contains no fluff or redundancy.

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

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

This is a simple polling tool with only two parameters and an output schema. The description covers the call pattern, the meaning of each parameter, and the default behavior when known_checkpoints is omitted. The output schema handles return-format details, so nothing necessary for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must supply meaning beyond the schema's bare types and titles. It does this thoroughly: run_id is defined as 'The run to check,' and known_checkpoints gets a full explanation including how new files are computed and the default behavior when omitted. This is richer than the schema alone.

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

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

The description states a specific verb and resource: 'Check if new .onnx checkpoint files appeared on disk.' It also adds the key behavioral detail that it 'Always returns instantly,' which clearly separates it from blocking wait tools. The mention of .onnx checkpoint files differentiates it from check_step, check_reward, and check_completion.

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 clear context for when to use the tool: checking for newly appeared checkpoint files during a run. It explains the polling pattern by telling the agent that known_checkpoints should come from a previous call and that new files are the current set minus the known set. It does not explicitly mention when not to use it or name alternative tools, but the intended use case is unambiguous.

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. It does disclose the key behavioral trait — "Always returns instantly" — which tells the agent this call never blocks, plus the content of the response. It does not disclose error behavior for an invalid or unknown run_id, but an output schema exists to document the return structure, so the main non-blocking trait being disclosed is meaningful context.

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

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

Two tightly written sentences with zero waste. The purpose is front-loaded, the key non-blocking behavior is in the first sentence, the return contents in the second, and the Args section is clean and minimal. Every sentence earns its place.

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

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

For a simple one-parameter, non-blocking check tool with an output schema, the description covers the essentials: what it does, that it returns instantly, what values it reports, and the parameter meaning. The main gap is the lack of explicit routing to sibling alternatives like wait_for_completion (for blocking until done) or check_step/check_reward (for individual values), which would improve orientation given the large sibling list.

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. The Args section says "run_id: The run to check," which adds real semantics beyond the schema's tautological "Run Id" title. It fully explains the parameter's purpose, though it omits format details such as whether the ID is a UUID or a run name.

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+resource: "Check if a training run has finished," and clarifies the scope by listing what it returns (status, step, reward, completion). It distinguishes itself from focused siblings like check_step and check_reward by being an aggregate check, and from wait_for_completion by emphasizing it "returns instantly," but it never names any 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 context is implied rather than stated. "Always returns instantly" signals that this is a non-blocking poll-style call, implicitly contrasting with the sibling wait_for_completion, and the aggregate return values imply you don't need separate check_step or check_reward calls. However, there is no explicit when-to-use or when-not-to-use guidance or named alternatives.

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

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

With no annotations provided, the description carries the full burden. It discloses the non-blocking behavior and the return contents (current reward, step, target reached), which is valuable context beyond the schema. It does not discuss error cases or explicitly state read-only behavior, but it is sufficient for a simple check 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?

The description is two focused sentences plus a compact argument list. Every sentence earns its place: the first defines the tool's purpose, and the second conveys essential non-blocking behavior and return fields.

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 two-parameter read-only check tool, the description is largely complete: it states the check condition, the non-blocking nature, and the returned information. It could more explicitly differentiate from sibling wait/check tools, but the current level is adequate for reliable selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. The provided arg descriptions ('The run to check', 'The reward threshold') add minimal meaning and mostly restate the parameter names. This is adequate but not rich; no format, units, or validation guidance is given.

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

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

The description clearly states a specific verb and resource: 'Check if mean cumulative reward reached a target threshold.' This uniquely distinguishes it from sibling tools like check_step, check_completion, and check_checkpoint, which target different resources.

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 statement 'Always returns instantly with current reward, step, and whether the target was reached' provides clear context that this is a non-blocking polling tool. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly discloses that the tool returns instantly and reports current step, reward, and target-reached status. It does not cover error conditions or side effects, but for a simple read-only check the disclosed behavior is substantial.

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

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

The description is compact and front-loaded with the core purpose, followed by the instant-return behavior. Every sentence adds value, and there is no wasted text or redundant boilerplate.

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 two-parameter polling tool, the description covers the essential behavior and return contents, and the presence of an output schema means return structure need not be spelled out. It is slightly incomplete in not mentioning prerequisites or explicit alternative usage, but these are minor for this 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. 'run_id: The run to check' and 'target_step: The step count target' add only slightly more than the schema's existing titles 'Run Id' and 'Target Step.' No constraints, formats, or clarifying details are provided, making the parameter guidance minimally useful.

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: 'Check if training reached a target step count.' It also adds the key distinction 'Always returns instantly,' which differentiates this from waiting siblings like wait_for_completion and wait_for_first_metrics.

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 'Always returns instantly' provides clear context that this is a non-blocking polling check rather than a wait operation. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. It reveals this is a destructive operation ('Kill') while reassuring safety via the 'not tracked by any active run' qualifier. It could add more about irreversibility or permissions, but the core behavior is transparent.

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. The destructive action and scope are front-loaded, followed by concrete trigger conditions. Every word earns its place.

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

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

This is a zero-parameter tool with an output schema and a clear, self-contained description. The agent knows what the tool does, when to invoke it, and what safety condition ensures it will not affect active runs. Nothing essential is missing.

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

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

The tool has zero parameters and schema coverage is trivially 100%. There is nothing for the description to add semantically, so the baseline of 4 applies.

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

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

Description states a specific verb ('Kill') and resource ('orphaned mlagents-learn and Unity build processes'), with a precise scope ('not tracked by any active run'). It clearly differentiates this from the sibling training/run-management 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?

Explicitly states when to use the tool: when force_training fails due to leftover processes occupying ports, or after a crash. It does not mention when not to use it or list alternatives, but the provided usage context is clear and actionable.

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 behavioral disclosure burden. It explains the 'trend' and 'last_n' behavior, but does not explicitly state that the tool is read-only, what happens if a run lacks the metric key, or whether runs must be in a specific state.

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

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

The purpose is front-loaded in one clear sentence, followed by a compact Args section with no filler. Every line adds useful information for calling the tool correctly.

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 3-parameter comparison tool, the description covers all parameters, required and optional, with practical examples and edge-case handling. The presence of an output schema means return-value documentation is not required, and the description is sufficiently complete for an agent to invoke the tool 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?

The schema provides only names, types, and defaults, while the description adds real semantics: run_ids are explicitly a list, metric_key gets a concrete TensorBoard example, and last_n explains 'trend' inclusion plus the special -1 behavior for all points. This fully compensates for the 0% schema description coverage.

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

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

The description uses a specific verb and resource: 'Compare a specific metric across multiple training runs'. It clearly distinguishes this from sibling tools like get_metrics or list_runs by emphasizing multi-run comparison and hyperparameter tuning.

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

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

The description provides clear usage context with 'useful for hyperparameter tuning' and implies the appropriate scenario: comparing the same metric across multiple runs. It does not explicitly name alternatives or exclusion conditions, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose key behavior: behavior_name 'searches all if omitted' and last_n controls how many recent items are returned, with -1 meaning all. However, it does not mention whether the operation is read-only, what happens for invalid run_ids, or any access requirements. This is adequate but has clear gaps.

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

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

The description is compact and efficient. The one-line purpose is front-loaded, followed by a concise Args block. Every sentence adds value, and there is no redundant restatement of the tool name or schema. It is appropriately sized for the tool's complexity.

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 description covers the core purpose and all parameter meanings, and an output schema exists to define return values, so it does not need to explain those. Given the tool's moderate complexity, the description is largely sufficient. It could be more complete by noting whether the operation is read-only or how results are ordered, but this is not a major 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 must fully compensate. It does: each of the three parameters gets a meaningful explanation beyond the schema—run_id identifies the run, behavior_name scopes the search and defaults to all, and last_n controls the number of results with -1 for all. The parameter semantics are complete and unambiguous.

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: 'Locate .onnx model files and checkpoints for a training run.' This clearly states what the tool does and differentiates it from the sibling tools, none of which focus on locating model files. The purpose is immediately understandable and not tautological.

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 clear context for when to use the tool: to query a training run and find model files or checkpoints. It explains the role of each argument, including the optional behavior_name and last_n controls. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of full explicit routing guidance.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It reveals that the training runs as a background process, that it always overwrites previous results for the same run_id, and that it blocks until ready with mode-specific conditions. It stops short of explaining process lifecycle details such as whether launch failures clean up partial processes, but the disclosed behaviors are important and clearly stated.

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 well structured: purpose and critical warning first, then blocking behavior, then a clean Args list. No sentence is purely decorative, and the overwrite warning is front-loaded where an agent will see it. The Args list is somewhat long, but it is necessary given the zero-coverage schema.

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

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

For an 11-parameter launch tool with no annotations, the description is fairly complete. It covers all parameters, explains the blocking semantics in both modes, and highlights the destructive overwrite behavior. Since an output schema exists, omitting return-value details is acceptable. A little more context about post-launch monitoring or failure cleanup would round it out, but the core operational picture is present.

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 the schema's silence. It does this by providing a one-line semantic explanation for every parameter, including useful details like torch_device example values, base_port auto-assignment, seed -1 meaning random, and the wait behavior split by mode. It could add more nuance, such as constraints on time_scale or port ranges, but it meaningfully enriches all parameters.

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

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

The description opens with a specific verb and resource: 'Launch a new mlagents-learn training run as a background process.' It clearly identifies what the tool does and immediately distinguishes it from resume_training by warning about overwriting previous results for the same run_id. This gives an agent a precise mental model of the tool's role.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: 'To continue from a checkpoint, use resume_training instead.' It also explains the two modes (editor vs batch) and the blocking behavior in each, which helps an agent decide how to invoke it and what to expect. This is strong, actionable usage guidance.

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

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

There are no annotations, so the description carries the transparency burden. It does disclose that the operation is a read and that config_path can be relative to the config dir or absolute. However, it does not describe what happens on a missing/invalid file, whether the YAML is parsed, or any other runtime behavior; the output schema may cover some of this.

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

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

The description is front-loaded with the purpose and then gives a single focused parameter explanation. There is no filler, repetition of schema metadata, or unnecessary detail.

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

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

For a one-parameter read tool with an output schema available, this is largely complete: the resource, file type, and path resolution rule are all stated. The main gaps are the undefined 'config dir' and the lack of any usage/alternative guidance, but the overall complexity is low enough that these are not critical.

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 input schema only defines config_path as a required string with no description. The description adds crucial meaning: it is a path to a YAML config file, and it may be relative to the config dir or absolute. This is exactly the semantic detail an agent needs to call the tool correctly, though 'config dir' itself is not defined.

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 operation and resource: 'Read a YAML training configuration file.' This is a specific verb + resource pair and naturally distinguishes get_config from siblings like update_config, which modifies, and force_training, which starts training.

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 explicit guidance about when to use this tool versus alternatives, no exclusions, and no related tools to consult. The only usage signal is implied by the word 'Read' and the tool name itself.

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

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

Without annotations, the description must carry behavioral disclosure on its own. It adds useful behavioral details like 'auto-detected if omitted' and default key sets, and 'Read' implies a non-mutating operation. However, it does not address error cases, availability of metrics, or any consequences of querying a run, so transparency is adequate but not rich.

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

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

The description is front-loaded with a one-line summary followed by a compact Args block. Every sentence adds value and there is no filler or repetition, making it easy for an agent to scan and extract the essential information quickly.

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

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

The description covers the tool's purpose and all four parameters with defaults and special cases, and an output schema exists so return-value details are not required. It is slightly incomplete in that it offers no guidance on prerequisites or comparison with related metric tools, but it is sufficient for correctly invoking 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 description coverage is 0%, so the description must fully compensate for missing parameter documentation. It does so: each parameter is explained with meaning, defaults, and special behavior (e.g., 'Use -1 for all' for last_n, 'auto-detected if omitted' for behavior_name). This is exactly the kind of semantic context the schema lacks.

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 begins with a strong verb and concrete resource: 'Read TensorBoard scalar metrics from a training run.' This clearly differentiates it from run-control and config tools, though it does not explicitly distinguish itself from similarly named siblings like get_training_logs, check_reward, or compare_runs.

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 is provided about when to use this tool versus alternatives. The description does not mention situations where get_training_logs, check_reward, or compare_runs would be more appropriate, leaving the agent to infer usage from the tool name 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?

Annotations are absent, so the description carries the behavioral burden. It discloses the main result contents (step progress, reward trend, checkpoints) and the effect of the last_n_* parameters. However, it does not explicitly state that the operation is read-only and non-blocking, relying on the verb 'get' to imply this. Given the low-risk nature of a status query, this is adequate but not particularly rich.

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 well-organized: a one-sentence purpose statement followed by a terse Args block. There is no filler, and the tool's purpose is front-loaded so an agent can quickly understand what it does.

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

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

For a simple read-style tool with an output schema present, the description adequately covers the input parameters and the returned content areas. It is only incomplete in not addressing sibling selection or explicitly stating its non-blocking nature, but that gap is already captured in usage guidelines. Overall, an agent has enough information 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%, and the description fully compensates by explaining all three parameters: run_id identifies the run, last_n_rewards controls the reward trend length, and last_n_checkpoints controls how many checkpoints are included. This adds real meaning beyond the bare schema properties, titles, and defaults.

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: 'Get detailed status of a training run' and lists the main content areas (step progress, reward trend, checkpoints). This distinguishes it from the narrower check_step, check_reward, and check_checkpoint siblings, though it does not explicitly differentiate it from get_metrics.

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 guidance on when to use this tool versus wait_for_completion, check_step, check_reward, or get_metrics. The 'get' wording implies an immediate snapshot, but the description never states that it is non-blocking or when it should be preferred over the many related sibling 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does state the source, the recency, and the active-run constraint, but it does not explain what happens for inactive runs, whether logs are combined, or whether the operation is strictly read-only beyond the word 'Get.'

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 concise and well-structured: a one-sentence purpose followed by a compact Args list. Every line earns its place, and the main behavioral constraint is front-loaded.

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

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

Given the tool's simplicity, the output schema exists to cover return values, and both parameters are described, the definition is largely complete. The main remaining gap is the lack of explicit guidance for edge cases such as querying a run that is no longer active.

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 provides useful, if minimal, explanations for both parameters: run_id is 'the run to query' and last_n_lines is the 'number of most recent log lines to return.' This adds meaning beyond the raw schema property names and types.

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

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

The description clearly identifies the verb 'Get' and the specific resource: 'recent stdout/stderr output from an active training run.' It is more precise than just 'get logs' and helps distinguish this from metric/status/config tools, though it does not explicitly name or contrast any sibling tool.

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

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

The description implies the primary use case: querying recent stdout/stderr logs for an active run. It does not explicitly state when to prefer this tool over siblings like get_metrics or get_run_status, nor does it explain behavior for completed or unknown runs.

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 it does reasonably well: 'List' signals a read-only operation, and the parameter explanations disclose filtering values, the default of 20, and the special -1 behavior. It does not discuss null filter semantics, but that is a minor gap for a simple listing operation.

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

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

The description is compact and well-structured, starting with a one-sentence purpose followed by a clean Args list. Every line adds value with no fluff.

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 low-complexity list tool with an output schema, the description covers the essential invocation details: what is listed, what statuses can filter it, and how many results are returned. The only minor ambiguity is that omitting status_filter is not explicitly described as returning all statuses, though the schema default of null makes this inferable.

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 fully compensate, and it does. It gives explicit allowed values for status_filter, explains last_n as the number of most recent runs, states the default 20, and documents -1 for all runs.

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 operation ('List') and the resource ('known training runs') along with the included status information. It is unambiguous, though it does not explicitly differentiate itself from sibling tools like get_run_status.

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

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

No guidance is given about when to use this tool instead of alternatives such as get_run_status, compare_runs, or wait_for_completion. The description explains what the tool does but not the conditions that should lead an agent to select it.

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 of behavioral disclosure. It adds meaningful behavior beyond the name: auto-detecting configuration, blocking by default, editor vs. batch mode wait behavior, and the wait_timeout mechanism. It does not fully describe side effects like process spawning or environment prerequisites, but the provided coverage is solid for an agent to understand what will happen.

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 focused and mostly front-loaded, with the core purpose and config behavior stated before the parameter list. The parameter list is compact and directly useful. A minor redundancy exists in 'run_id: The run_id to resume,' which could be more descriptive, but overall there is no meaningful fluff.

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

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

Given the tool's complexity and the lack of annotations, the description is reasonably complete: all parameters are explained, the default blocking behavior is disclosed, and editor/batch mode differences are covered. An output schema exists to describe return values, so that gap is acceptable. The description could have mentioned that force_training should be used for brand-new runs, but it is not a critical omission.

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 the missing parameter documentation. It does this well: every one of the 8 parameters receives a functional explanation, including key nuances like config_path auto-detection, wait behavior differences, and time_scale meaning. This goes well beyond the bare schema titles.

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 clear, specific statement: 'Resume a previously stopped/completed training run.' This identifies both the action and the resource, and distinguishes it from the sibling force_training by focusing on resuming an existing run rather than starting a new one.

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 clearly implies when to use this tool: when a training run already exists and needs to be continued. It also references force_training as the behavioral baseline for blocking behavior, which gives the agent some cross-tool context. However, it does not explicitly say 'use force_training for new runs' or list exclusions, so the guidance is slightly implicit rather than fully 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 to rely on, the description carries the behavioral disclosure burden and does so well: it reveals that SIGINT is sent, that the model is saved, and that after timeout the process is force-killed. This gives an agent a clear understanding of side effects and shutdown semantics, though it does not mention other potential effects on logs, state, or child processes.

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, with the primary behavior in the first sentence and parameter details in a short list. Every sentence contributes useful information, and there is no filler or repeated schema content.

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

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

For a two-parameter, single-action tool, the description is largely complete: it explains what happens on stop, what timeout does, and the parameters are fully documented. The presence of an output schema covers return-value expectations, and the only notable gap is the lack of explicit guidance on when to choose this tool over related 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?

Schema description coverage is 0%, so the description must explain the parameters, and it does. run_id is defined as "The run to stop," and timeout is defined as "Seconds to wait for graceful shutdown before force-killing," adding meaningful behavioral meaning beyond the bare schema titles.

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: "Gracefully stop a running training run," and adds the concrete mechanism "sends SIGINT so the model is saved." This clearly differentiates the tool from siblings like resume_training and force_training by emphasizing graceful behavior and signal-based stopping.

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

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

The description implies the tool is used when a training run is running and needs a graceful stop, and it introduces "force-killing" as the fallback after timeout. However, it does not explicitly state when to prefer this tool over alternatives such as force_training or cleanup_processes, nor does it list conditions where it should not be used.

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 discloses meaningful behavior: updates are deep-merged and unspecified keys are preserved. However, it does not mention side effects such as whether the file is created if missing, whether changes are written immediately, or what happens on invalid paths or merge conflicts.

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 focused sentences plus a compact Args section. The core behavior is front-loaded, and every sentence adds value: it defines the operation, states the preservation guarantee, and explains the two parameters with no redundancy or filler.

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

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

The description covers the core update semantics and both parameters, and an output schema exists so return-value documentation is not necessary. However, it omits practical guidance about whether the config file must already exist, how paths are resolved, or any error scenarios, leaving gaps for a mutation tool with no annotations.

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 parameter semantics must come from the description. It explains config_path as 'Path to the config file (relative to config dir or absolute)' and updates as 'Dictionary of updates to deep-merge into the config', adding real meaning beyond the schema's bare 'string' and 'object'. More detail about merge behavior for nested structures would be richer, but the basics are well covered.

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 verb 'Deep-merge updates' and the resource 'existing YAML config file', specifying the scope of the operation with 'Only specified keys are changed'. It is easily distinguishable from sibling tools like get_config, which is a read operation, and resume_training, which has a different purpose.

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

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

The description implies usage context by indicating this is for updating an existing YAML config, and the 'Only specified keys are changed' note suggests partial updates. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention constraints such as the file already existing or authorization requirements.

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 of behavioral disclosure. It clearly warns that the tool 'WILL freeze the conversation until training ends or timeout' and documents the default timeout. This is strong transparency for a blocking operation, though it doesn't describe what happens on timeout or failure.

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 tight and front-loaded: purpose, usage pattern, behavioral warning, and default timeout in the first four sentences, followed by a clean args list. Every sentence earns its place; no fluff 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?

The description covers purpose, usage, blocking behavior, timeout, and all parameters. An output schema exists, so return values need not be described. The main gap is the unspecified behavior when timeout expires or when the run does not exist, which would help an agent reason about edge cases in a 4-hour blocking call.

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 schema has 0% parameter description coverage, so the description must compensate. It does so thoroughly: run_id is 'The run to wait for,' timeout is 'Max seconds to wait (default 14400 = 4 hours),' and poll_interval is 'Seconds between internal status checks (default 60).' This adds meaningful semantics and defaults beyond the raw 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 opens with 'Block until a training run finishes,' a specific verb and resource that clearly defines the tool's behavior. It distinguishes itself from siblings like wait_for_first_metrics (which waits for an earlier milestone) and check_completion (which likely checks status non-blockingly).

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 explicitly states the intended usage pattern: 'Use this to chain runs automatically: start skill A, wait_for_completion, then start skill B.' It provides clear context for when to use the tool, though it does not explicitly identify alternatives or when not to use it.

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 behavioral disclosure burden. It clearly discloses that the tool blocks until data appears, provides a typical duration estimate of 1-2 minutes, and explains timeout and polling behavior through the args. It does not detail timeout failure behavior, but the core blocking nature is transparent.

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

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

The description is front-loaded with the main purpose, then gives a usage hint and timing expectation, followed by a compact Args list. Every sentence adds value and there is no redundant filler.

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

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

For a simple polling tool with an output schema available, the description covers the key operational context: what it waits for, when to call it, and how long it typically takes. It could have explicitly contrasted with siblings like wait_for_completion, but this is a minor gap given the clear first-metric focus.

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 so fully by defining all three parameters: run_id ('The run to watch'), timeout ('Max seconds to wait'), and poll_interval ('Seconds between checks'). This adds clear meaning beyond 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 uses a specific verb ('Block') and resource ('training run produces its first TensorBoard metric data point'), making the tool's function unambiguous. It also distinguishes itself from siblings like wait_for_completion by focusing on the first metric data point rather than overall completion.

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 clearly states when to use the tool: 'Use this right after starting training to know when data starts flowing.' It does not explicitly mention alternatives or when not to use it, but the context is clear enough to guide an agent.

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