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

No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful behavioral fact that lower lpips is better, which an agent could not infer from the schema. However, it never confirms the operation is read-only, and it does not describe the shape of the result (ranking order, how the best run is marked, tie handling).

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

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

Two short sentences, front-loaded with the core action and followed by the one non-obvious domain fact. Nothing is padded or repeated from the name.

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

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

This is a small read-style tool with two required parameters and no output schema. For that complexity the description covers the action and the key metric-direction nuance, though with no output schema it leaves the agent guessing at the return format. That is the one real gap.

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

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

Schema coverage is 50%: 'runs' is documented in the schema and the 'metric' parameter has an enum, but its semantics are undocumented there. The description compensates for the metric parameter by explaining that lower lpips is better, which is meaningful added value, but it says nothing about how multiple runs are supplied or what happens with one run.

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: rank runs by a final metric and identify the best. This is clearly distinct from the read-oriented siblings (get_final_metrics, get_metric_curve) because it produces a ranking verdict, though it never explicitly names or contrasts those siblings.

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

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

Usage is only implied: you gather that it is for comparing multiple runs. There is no explicit "use this instead of get_final_metrics when..." guidance, no mention of prerequisites such as needing completed runs, and no exclusion cases.

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 must carry the behavioral load. It does disclose the concrete diagnostic categories it evaluates, which is useful, but never states that it is read-only, what the report/return shape looks like, or how expensive the check is — meaningful gaps for an unannotated 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?

Two sentences: the check list is front-loaded and the purpose clause follows. Every phrase carries information; no 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 single-parameter read diagnostic with no output schema, the description covers what is inspected and why you'd call it. The main remaining gap is what the result actually looks like (issue list? pass/fail summary?), which matters slightly more given no output schema exists.

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

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

Schema description coverage is 100% and the schema already explains the run name with an example ('lego_baseline'). The description adds no further parameter semantics, so the baseline 3 applies.

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

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

States a specific verb ('Check') applied to a specific resource ('one run') and enumerates the exact conditions it looks for (missing final eval, NaN/inf loss, loss spikes, early stopping, too many Gaussians). This clearly separates it from list_runs, compare_runs, get_metric_curve and other siblings.

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

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

'Use it to explain why a run failed or has no results' gives a concrete triggering condition. It stops short of naming alternatives or exclusions (e.g., when to prefer compare_runs or get_final_metrics), so it is clear context without explicit routing.

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

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

With no annotations, the description carries the disclosure burden and does useful work: it names the three concrete metrics returned and warns that a run without an evaluation yields status 'no_eval'. This prevents an agent from misreading a sentinel as an error. It does not describe the response shape beyond the metric keys, keeping it short of a 5.

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

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

Two tight sentences with the core action front-loaded and the edge-case behavior second. No redundant restatement of the tool name and nothing extraneous to trim.

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 no output schema, the description covers the key return facts: which metrics come back and the 'no_eval' fallback. Slightly incomplete in that it doesn't indicate return structure (flat keys vs nested) or units, which matters when no output schema is published.

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

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

There is a single required parameter at 100% schema coverage, and the schema already supplies the format and provenance ('exactly as returned by list_runs, e.g. lego_baseline'). The description's 'of one run' only reinforces what the schema documents, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the final test metrics') and enumerates exactly which metrics (psnr, ssim, lpips) for a single run. The word 'final' implicitly contrasts with get_metric_curve, but no sibling is named explicitly.

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

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

The description says what the tool returns but never says when to prefer it over get_metric_curve or compare_runs, nor any prerequisite (e.g. that an eval must have been run). The only condition mentioned, 'no_eval', is a return state rather than a usage rule.

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

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

No annotations are provided, so the description carries the burden; it does disclose that the curve is downsampled and that the last value is included, which is real behavioral context. It omits what happens for unknown metrics, the downsampling method, and any permission/limit behavior.

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

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

A single front-loaded sentence with zero waste: verb, resource, qualifier ('downsampled'), examples, and the extra return element ('last value').

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 read-only curve lookup with no output schema and full parameter documentation, the description covers what is returned and the key qualifier (downsampling). Minor gap: no guidance on behavior for missing runs/metrics or on how many points to request.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaningful examples of metric names (loss, train_psnr, num_gaussians) that the schema does not enumerate, helping the agent understand what 'metric' accepts.

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: 'Get a downsampled training curve of one logged metric plus its last value', with concrete metric examples. It distinguishes itself in spirit from get_final_metrics by emphasizing the curve and downsampling, but never names a 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?

The description implies usage (fetch a time series for one metric) and the schema defaults ('loss', 10 points) hint at typical calls, but there is no explicit when-to-use guidance such as curve vs. get_final_metrics vs. compare_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?

No annotations are provided, so the description carries the full burden. The "Get" verb signals a read-only operation and the parenthetical enumerates the returned fields, but nothing is said about behavior when the run name is unknown, or whether the values reflect initial vs. resolved/final settings.

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

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

A single front-loaded sentence with no wasted preamble. The trailing ellipsis in the parenthetical is slightly loose but does not obscure 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?

For a simple one-parameter read tool with full schema coverage this is close to sufficient, and the field list hints at the return shape despite no output schema. However, it is ambiguous about whether the config is the requested or the actually-applied configuration, which matters for a diagnostic 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 100% and the single parameter's schema description already specifies "run name exactly as returned by list_runs, e.g. 'lego_baseline'". The tool description adds no further meaning beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb and resource ("Get the training config of one run") and names the contents (iterations, learning rates, densification settings). It is naturally distinct from the siblings (list_runs, get_final_metrics, get_metric_curve, compare_runs, diagnose_run), but it never explicitly contrasts itself with them.

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 "of one run" implies this is the single-run lookup versus compare_runs for multi-run work, but that routing is left to inference. There is no explicit when-to-use, when-not-to-use, or prerequisite (e.g. that the run must already exist).

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 must carry the behavioral load, and it does disclose useful semantics: the return fields and the meaning of each status ('finished' has final metrics, 'no_eval' does not). It omits the read-only assumption, ordering, pagination and any permission requirements, so the transitive behavior is only partially covered.

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, each earning its place: the first declares content and field semantics, the second declares the call-order guidance. It is front-loaded with the purpose and wastes nothing.

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 list tool with no output schema, the description covers purpose, returned fields, status semantics and call-order advice. Ordering and pagination are unstated, but otherwise an agent has what it needs to invoke it correctly.

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

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

There is only one parameter and the schema describes it fully ('Only list runs of this scene, e.g. lego'), so the baseline is 3. The description adds no filtering syntax or default behavior beyond what the schema already states.

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?

It states a concrete verb (list) and resource (training runs) and names the fields the listing exposes (scene, planned iterations, status), which an agent can act on without opening the schema. It never names the sibling get_* tools it is meant to precede, so differentiation is implied rather than explicit.

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

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

'Call this first if you don't know the run names' gives a clear entry-point condition that separates discovery from the follow-up tools like get_run_config or get_final_metrics. It doesn't state when not to use it or name alternatives explicitly, 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.