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

With no annotations, the description carries the full behavioral burden. It usefully discloses that cancellation affects queued or active work and preserves completed stages, but it does not state irreversibility, permissions, in-progress stage behavior, or resulting job 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 description is a single front-loaded sentence with no wasted wording. It conveys the core action and key retention behavior efficiently.

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

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

For a simple one-parameter mutation tool with no annotations or output schema, the description covers the core effect but omits parameter guidance and important cancellation side effects. It is minimally adequate but 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%, and the description does not mention job_id at all. While the sole required parameter is named clearly, the description adds no meaning about where to obtain it, its format, or what happens if the job is already complete.

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: cancel queued or active generation work. It also clarifies scope by saying completed stages are retained. It does not explicitly differentiate itself from siblings such as pause_generation_batch or cleanup_generation_job, so it falls short of a 5.

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

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

The description implies when to use it by mentioning queued or active work, but it gives no explicit when-not guidance or alternatives like pause_generation_batch or cleanup_generation_job. The usage context is present but incomplete.

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

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

With no annotations, the description carries the full behavioral burden and usefully discloses both removal of job data and default preservation of final deliverables. It does not explain whether removal is irreversible, exactly what data is deleted, or how running jobs are affected.

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

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

The single compact sentence front-loads the destructive action and immediately states the important preservation default. Both clauses add invocation-relevant information without 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 basic action and default are clear, but the absence of annotations and an output schema leaves important gaps for a destructive operation. Deletion scope, permanence, job-state prerequisites, and the expected outcome are not described.

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. Preserving final deliverables gives practical meaning to keep_final beyond its boolean type and title, while job_id is only implicitly identified as the target job with no format or source guidance.

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: "remove job data," and clarifies that final deliverables are preserved by default. It does not explicitly distinguish this cleanup operation from lifecycle siblings such as cancel_generation.

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?

Deliberate cleanup while retaining final outputs is an implied use case. However, there is no guidance about eligible job states, when cleanup should occur, or when to use cancel_generation or artifact-retrieval tools instead.

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 supplied, the description carries the full burden and does disclose two important behaviors: a hard cap of 1000 assets, and that image creation is performed by the calling Codex agent rather than by this tool. It still omits what the tool returns (batch id?), whether queueing is idempotent, what happens on partial failure, and what the 'launch queue UI' side effect actually does.

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

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

It is short and front-loaded with the core action and limit, and the asset field list is efficient. The telegraphic final two clauses ('launch queue UI', 'continue the agent repair/review loop') are compressed to the point of ambiguity and mix UI side effects with agent workflow in the same block.

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, no-output-schema, no-annotation tool, the description covers the input shape well and states the capacity limit and who performs generation. It stops short of describing the result of queueing or how this call relates to get_batch_status / open_generation_queue, leaving the agent without a clear next step beyond the generic get_agent_work pointer.

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 assets array is typed only as an unconstrained object, so the description does real work by naming the required 'prompt' field and the optional name, seed, quality, material_hints, and views {front,back,left,right} members. The top-level 'name' parameter (presumably the batch name) is left undescribed, which is the only real gap.

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 ('Queue up to 1000 named assets before generating references') and states the capacity limit, which is concrete and actionable. It is somewhat muddied by the appended 'launch queue UI', which overlaps conceptually with the sibling open_generation_queue, so the boundary between the two is not fully clean.

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

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

It implies the usage context ('before generating references') and points at a follow-up tool ('Read get_agent_work and continue the agent repair/review loop'), which is useful sequencing guidance. However, it never states when NOT to use this versus open_generation_queue, get_batch_status, or the submit_* siblings, so the agent must infer the 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 full burden and does real work: it discloses serial-queue limits, that a paused batch stays paused, that creating a candidate never approves or replaces the master, and that mutations need an explicit recipe policy region. It does not explain idempotency_key behavior (duplicate submission semantics) or whether the call is synchronous, which are the main behavioral gaps.

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

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

Five short sentences, front-loaded with the core action and the source_attempt branch before the caveats. Some terminology ('typed repair', 'raw shape', 'recipe policy region') is unexplained jargon, but nothing is 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?

For a 9-parameter mutation with a nested recipe object, no annotations, and no output schema, the description leaves most inputs and the entire return shape undocumented. An agent cannot tell what an attempt looks like on success or how to safely retry, which is a substantial gap for this complexity level.

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

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

Schema description coverage is 0% across 9 parameters, and the description only explains source_attempt (zero vs. positive) and hints at a recipe policy region. Critical parameters such as idempotency_key, expected_shape_attempt (apparently an optimistic-concurrency token), source_sha256, inspected_paths, and the nested recipe object are left completely undefined, so an agent must guess their semantics.

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

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

The opening clause gives a specific verb and resource: 'Queue one typed repair' tied to a shape-repair attempt, and the second sentence clarifies the source_attempt branch. It gestures at a sibling ('Use submission for imported edits') but never names submit_shape_repair_candidate explicitly, so differentiation is implied rather than stated.

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

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

It gives concrete routing conditions: zero source_attempt means work from the raw shape, positive source_attempt means work from a retained candidate, and imported edits should go through 'submission' instead. What is missing is a named alternative tool and any statement of when not to call this at all (e.g., when the batch is cancelled or the asset is locked).

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 at all, the description carries the full behavioral burden and falls well short. It does not state that the job is asynchronous, whether a job identifier is returned for later status/artifact retrieval, what happens if only the front view is supplied, whether generation is costly or rate-limited, or whether the operation can be cancelled.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is under-specification rather than disciplined conciseness given 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?

For a nine-parameter generative job tool with no annotations and no output schema, the description is far too thin. An agent cannot tell what the call returns, how to track completion, or how the optional view paths and quality settings interact, all of which the description would need to supply.

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 there are nine parameters, so the description must compensate and largely does not. 'Named canonical views' gives some hint that the image path parameters are per-view, but prompt, seed, quality, material_hints, and generate_texture receive no meaning at all, including how the quality enum affects the job.

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

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

The description gives a specific verb ('Start') and resource ('Hunyuan3D-2mv job') and scopes it to multiview input from 'named canonical views', which maps onto the front/back/left/right image parameters. It distinguishes itself from job-control siblings like get_generation_status or cancel_generation, though it does not differentiate itself from create_generation_batch.

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 when-to-use guidance, no prerequisites, and no named alternative. The word 'durable' faintly implies an async job that must later be polled, but the agent is left to infer that from sibling names rather than from the description.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It implies a read of pending work but says nothing about ordering, pagination, whether results are consumed/claimed by reading, what happens when no work exists, or what the response contains — all material for a work-queue 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 front-loaded sentence with no filler, so it is concise, but conciseness here tips into under-specification — the one clause leaves core questions (filtering, return shape, relationship to sibling tools) unanswered.

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, zero-coverage, annotation-free tool sitting among nineteen overlapping generation/queue siblings with no output schema, the description is far too thin. It does not compensate for any of those structural gaps, so an agent must guess at 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 never mentions either parameter. "batch_id" is undocumented in both places, so an agent cannot know whether it narrows to a specific batch or is required for meaningful results; "limit" is likewise unaddressed with no default or max behavior explained.

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 verb ("Get") and a resource ("active-phase image generation, visual review or repair tasks") scoped to a specific agent, which is more than a tautology. However, "active-phase" is unexplained jargon and the tool is not distinguished from close siblings such as get_generation_status, get_queue_status, or get_batch_status, so an agent cannot easily tell which of these retrieves actual work items versus job state.

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

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

There is no guidance on when to call this versus the many state-inspection siblings, no prerequisites, and no stated exclusions. The description also omits any hint about the practical use case (e.g., polling for next work item after claiming a job), leaving usage entirely 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?

No annotations are supplied, so the description carries the full burden of behavioral disclosure. 'Read' and 'durable' weakly imply a non-mutating, persisted-state query, but nothing is said about whether the call blocks, whether it reflects in-flight attempts, how large the payload is, or what happens for an unknown or expired batch_id.

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

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

It is a single compact sentence with no filler, which is good, but the telegraphic list style makes it read like a field dump rather than a clear statement of intent. Brevity here is close to under-specification rather than efficient communication.

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 has no annotations and no output schema, so the description is the only source of information about behavior and return content, and it provides only a bare enumeration of facets. For a status-query tool used in a large multi-tool batch workflow, that leaves key questions (return shape, freshness, error cases) unanswered.

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 required parameter (batch_id) with 0% schema description coverage, and the description never mentions it, so no meaning is added beyond the schema's name and type. With low coverage the description should explain the identifier's origin (for example, returned by create_generation_batch), but 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?

The verb 'Read' plus the enumeration of returned facets (phase, assets, attempts, gates, pending agent actions) signals this is a status-inspection tool for a batch, so the general purpose is inferable. However, it never names the resource explicitly as a 'batch' beyond the tool name, and it gives no differentiation from siblings such as get_queue_status or get_generation_status, which an agent could easily confuse it with.

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

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

There is no statement of when to call this versus get_queue_status, get_generation_status, or get_agent_work, and no mention of prerequisites such as needing a valid batch_id or a batch being in a certain state. The agent must infer usage purely from the tool name and the sibling list.

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

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

With no annotations, the description carries the full burden, and it does disclose the return shape (paths plus SHA-256 hashes) and hints that artifacts may not all exist ('every available'). It does not say what happens if the job is unknown, still running, or has no artifacts, nor whether the call is read-only, so meaningful gaps remain.

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

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

One front-loaded sentence with no filler; the payload is named first and nothing is repeated from the title or 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 a one-parameter read tool with no output schema, describing the return payload is the right move and it does so. However, without an output schema the agent still lacks detail on the structure of the returned paths/hashes and on error behavior, leaving it only minimally complete.

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

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

The single parameter job_id has 0% schema description coverage, and the description never mentions it or clarifies which job identifiers are accepted. The one required input is therefore undocumented in both structured and unstructured data.

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 ('Return') and a specific payload ('paths and SHA-256 hashes for every available job artifact'), so the agent knows exactly what comes back. It does not differentiate itself from nearby siblings such as get_generation_status, which also relates to a job, so it falls short of a 5.

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

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

There is no when-to-use guidance, no prerequisites (e.g. job must exist or be complete), and no named alternative. The agent must infer that this is a post-generation fetch and guess how it relates to get_generation_status or cleanup_generation_job.

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

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

With no annotations, the description carries the full burden, and it does contribute real signal: 'durable state' implies the status survives beyond a single request, and 'warnings' signals partial-failure reporting. It still omits whether the call is read-only (only implied), what happens for an unknown or expired job_id, and whether polling is expected.

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

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

One front-loaded sentence with no filler, and the list of returned fields is grouped logically. It is arguably too terse for a tool with no annotations, but nothing in it 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?

For a simple one-parameter read tool this is close to adequate, and the enumeration of returned fields partly substitutes for the missing output schema. However, with no annotations and an undocumented parameter, the definition leaves the agent guessing about polling behavior and how it differs from the several sibling status tools.

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

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

The schema has 0% description coverage and the single required parameter job_id is never mentioned in the description, so nothing explains its format, provenance, or expected lifetime. The description does not compensate for the coverage gap.

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

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

The description names the returned data precisely (durable state, stage, progress, warnings, artifacts), making it clear this is a status/progress read for a generation job. It does not, however, state the resource explicitly or distinguish itself from siblings like get_batch_status, get_queue_status, or get_generation_artifacts.

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

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

There is no when-to-use guidance at all: no mention of polling, of checking a single job vs a batch/queue, or of when to call get_generation_artifacts instead. An agent must infer the choice from the tool names alone.

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

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: the call is cheap and does not hash model artifacts. It leaves out whether the operation is strictly read-only, whether it may touch a running generation, or what the returned state contains, so the safety and cost profile 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?

One front-loaded sentence with no filler. The trailing "without hashing model artifacts" clause is meaningful contrast but is written as jargon only intelligible once the sibling tools are known.

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?

A zero-argument read tool is simple enough that a short description is defensible, and no output schema exists to carry return-value information. However, the description never states what queue or resource fields come back, which is the main thing a polling agent needs before calling.

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 and the baseline of 4 applies. The single caveat is that no arguments at all means the caller cannot scope the query, which the description does not acknowledge.

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?

"Read lightweight queue and resource state" gives a verb and a rough resource, but "resource state" is vague and the description never distinguishes this from close siblings like get_batch_status or get_generation_status. The clause about not hashing model artifacts hints at a scope difference without naming what the tool actually reports.

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: "lightweight" and "without hashing model artifacts" suggest this is the cheap polling option rather than the artifact-hashing status tools. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the routing rule from a single adjective and a contrast clause.

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 full behavioral burden, and it only partly does. 'Read' implies a side-effect-free lookup, and the caveat that discovery is not runtime qualification is a genuinely non-obvious warning about the scope and trustworthiness of the result. However, it says nothing about return shape, whether the capability registry can be stale, auth requirements, or caching.

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?

Eleven words, front-loaded, with no filler or hedging. The terseness is efficient structurally, though the compression is part of why the purpose reads as cryptic rather than because wording was trimmed.

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

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

For a zero-argument discovery tool with no output schema, the description is the only place a caller can learn what comes back — the 'typed methods' and the 'gate policy' fields — and it does not say. The one caveat about runtime qualification is helpful, but the definition leaves the agent guessing at the payload it will need to interpret.

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 and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter detail is owed here.

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

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

The verb 'Read' plus 'typed methods and gate policy' gestures at a discovery tool, but 'typed methods' and 'gate policy' are unexplained jargon that an agent cannot resolve without already knowing the domain. It tells the reader almost nothing beyond what the name 'get_shape_repair_capabilities' already implies, and does nothing to separate this from sibling discovery tools like get_batch_status or get_queue_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?

The clause 'discovery is not runtime qualification' is a useful negative constraint — it warns against treating this output as proof that a repair can actually run — but it never states the positive condition for calling the tool or names an alternative. No sibling tool is referenced, so the agent has no routing signal.

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 full behavioral burden, and it does disclose that the target is a *local* dashboard whose controls include preview, pause, resume, and cancel. It does not say what the call returns (a URL? a launched browser?), whether it has side effects on the host, or what happens in headless/no-display environments — meaningful gaps for a UI-launching 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 front-loaded sentence with the action, target, and capability set, and no wasted words. It is exactly as long as the information it conveys.

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-parameter, no-output-schema tool, the description covers what it does and roughly what the agent/user will find there. The only real omission is the return value and the side effect of launching a local UI, which is modest given the tool's simplicity.

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

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

The tool takes zero parameters, so the schema needs no compensation and the baseline of 4 applies. Nothing in the description misrepresents the parameter surface.

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

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

A specific verb ("Open") plus a specific resource ("local queue dashboard") tells the agent exactly what happens, and the phrase "previews and pause/resume/cancel controls" signals this is a UI surface rather than the programmatic controls in siblings like pause_generation_batch or cancel_generation. It stops short of naming any sibling outright, so differentiation is implicit 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?

Usage is only implied: an agent can infer this is for when a human wants to view and manipulate the queue visually, while get_queue_status or pause_generation_batch are the machine-facing equivalents. There is no explicit when-to-use, when-not-to-use, or named alternative.

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

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

With no annotations, the description carries the full burden. It usefully discloses that pausing happens at the asset boundary and releases the worker before more work starts, but it omits reversibility, permissions, effect on queued work, and response 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 no wasted words. It prioritizes the key boundary behavior immediately.

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 mutation tool with one parameter and no output schema, the description explains the core pause behavior but leaves important context missing: when to choose pause over cancel, how resumption works, and what the caller should expect after the worker is released.

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 only parameter, batch_id, is never mentioned in the description, and schema description coverage is 0%. The description adds no meaning beyond the schema's type and title for this required 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?

The description states a specific action (pause) and a meaningful timing constraint (at the current asset boundary), which distinguishes it from an immediate cancel. It does not explicitly name the batch resource, but the tool name supplies that context.

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

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

It gives no explicit guidance on when to use this tool versus cancel_generation or resume_generation, and no prerequisites or exclusions are stated. The pause semantics imply usage, but alternatives are left to inference.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the tool cannot override a failed gate, but it omits write semantics, idempotency, permission requirements, validation of inspected_paths, and what happens when a review is recorded repeatedly.

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 definition is a single front-loaded sentence with no wasted wording. It is appropriately concise, though the terseness contributes to gaps covered under other dimensions rather than excess verbosity.

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

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

This is a complex seven-parameter mutation tool with no annotations, no output schema, and no schema descriptions. The description adds one important guardrail but leaves most operational context missing, including return behavior and how gate status interacts with approved.

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 seven required parameters, so the description must compensate. It only loosely gestures at 'current-attempt evidence' and the failed-gate constraint; it does not explain batch_id, asset_id, stage, attempt, approved, notes, or inspected_paths formats and interactions.

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 object: 'Record the agent's inspection of current-attempt evidence,' which is clearer than a tautology. It does not, however, explicitly distinguish this tool from sibling review or retry tools, so the scope is clear but sibling differentiation is missing.

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 'cannot override a failed gate' gives one usage restriction, but the description never states when to call this versus alternatives such as retry_asset_stage, nor does it explain prerequisites like the relevant stage or attempt lifecycle.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that resumption happens 'from verified outputs,' which is useful and distinguishes it from a full restart, but it omits whether the operation is mutating, idempotent, costly, permission-gated, or what happens if the job is not resumable.

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 definition is a single front-loaded sentence with no filler. Its brevity contributes to the gaps elsewhere, but the sentence itself is efficient and easy to parse.

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

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

For a job-control operation with no annotations, no output schema, and an undocumented required parameter, the description is thin. It leaves out prerequisites, how to discover a resumable job_id, expected outcomes, and failure 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?

The single parameter has 0% schema description coverage, and the description does not explain what job_id is, where to obtain it, or what format it takes. It only implies that a job identifier is needed, adding little beyond the bare schema field 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 uses a specific verb and resource ('Resume ... job') and narrows the scope to interrupted or repairable failed jobs, so an agent can distinguish it from generic retry/stage-repair siblings. It does not explicitly name an alternative sibling tool, keeping it below a 5.

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

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

Usage is implied by 'interrupted or repairable failed job,' which gives a condition for use. However, it does not state when not to use it, how it differs from retry_asset_stage or create_shape_repair_attempt, or what makes a job 'repairable' versus simply failed.

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 add one genuinely useful fact — that successful other assets are retained — but says nothing about whether the retried stage's prior output is discarded, whether the operation is idempotent, what preconditions must hold, or what it returns. 'Rewind its cause' asserts a second behavior mode without explaining it.

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

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

It is a single front-loaded sentence with no filler, which is structurally sound. But the economy is achieved by omitting substance rather than by compressing it — the phrase 'rewind its cause' is compressed to the point of being unparseable.

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 state-mutating retry operation with no annotations, no output schema, five required parameters, and a nested free-form object. Against that complexity, one sentence stating retention semantics is far short of what an agent needs to invoke it correctly or predict its effect.

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?

Five required parameters with 0% schema description coverage, including a free-form nested 'changes' object with additionalProperties, and the description explains none of them. It never clarifies what belongs in 'changes', what 'repair_note' is for, or how 'batch_id'/'asset_id'/'stage' interact, so the agent gets no compensating meaning from the prose.

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

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

The verb 'resubmit' and the object 'an agent-repaired stage' give a rough sense of the operation, and 'retaining successful other assets' hints at partial-retry scope. However, 'rewind its cause' is opaque, and the definition never distinguishes itself from plausible siblings such as create_shape_repair_attempt, submit_shape_repair_candidate, or resume_generation. An agent would need to open the schema and guess.

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?

Only the implied condition 'agent-repaired' suggests a usage context; there is no explicit when-to-use, when-not-to-use, or alternative named among the eighteen siblings. Given the dense cluster of repair/retry/resume tools, this is a meaningful gap that leaves routing ambiguous.

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 burden. "Report" plus a zero-argument schema strongly implies a read-only snapshot with no side effects, and the enumerated checks tell the agent what dimensions are probed. However, it does not state whether the check is passive or actively probes the GPU/runtime (which could be slow), nor whether results are cached.

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

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

A single front-loaded sentence with no filler; every item in the list is a distinct thing being checked. Nothing could be cut without losing information.

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

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

For a zero-parameter, no-output-schema diagnostic tool, naming the five readiness dimensions effectively describes the return payload. The remaining gap is operational: no hint about cost/latency of the probe or how to interpret a not-ready result, which for a health check an agent may call in a retry loop would be useful.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The schema is empty and fully self-evident.

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?

"Report" is a specific verb and the resource is enumerated concretely: Hunyuan runtime, model cache, GPU dependencies, disk, and queue readiness. That is enough to distinguish it from the narrower siblings like get_queue_status or get_generation_status, though the description never explicitly says it is a server-wide health check versus those targeted status tools.

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

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

Usage is only implied: an agent can infer this is the pre-flight/diagnostic check to run before generation work. There is no explicit statement of when to prefer it over get_queue_status or get_generation_status, and no mention of prerequisites or how often to call 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 at all, the description carries the full disclosure burden, and it delivers very little. "Immutable" hints outputs are write-once and "pixel gates" implies validation can fail, but it never says what is created, what happens when a gate fails, whether re-submission is allowed, or whether this mutates batch 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?

It is a single short, front-loaded sentence with no filler, which is good, but the compression has been taken too far for a tool with this much surface area. Brevity here reads as under-specification rather than efficiency.

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 8-parameter, 6-required mutation-style tool with no annotations, no output schema, and zero schema descriptions, one cryptic sentence is far from sufficient. Essentials an agent needs before calling — expected path format, gate failure behavior, and prerequisite state — are all absent.

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

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

Schema description coverage is 0% across 8 parameters and the description explains none of them. It never mentions that four image paths are required, what key_color expects (RGB triple?), or how background_mode's auto/transparent/chroma options behave, so the agent is left guessing on a fully undocumented 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 sentence names effects ("immutable RGBA cutouts", "pixel gates") but never states the actual operation: submitting front/back/left/right reference images for an asset in a batch. It does not differentiate from siblings like record_asset_review or retry_asset_stage, so an agent must infer the intent from the tool name and 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?

"Agent visual review is next" is the only usage signal, and it only hints at workflow ordering relative to one unnamed downstream step. There is no statement of preconditions (e.g., batch must be open), no when-not-to-use case, and no comparison against record_asset_review or retry_asset_stage.

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 disclosure burden and does supply useful behavior: staging is immutable, gates run before anything is queued, and validation/evidence is queued asynchronously rather than resolved inline. It omits what happens on a SHA-256 mismatch, whether resubmission with the same idempotency_key is safe, and what identifiers come back from the queued 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?

Three short sentences, front-loaded with the action and followed by prerequisites and the negative scope. No filler or restatement of the tool name. Slightly compressed to the point that a few clause fragments ('an explicit region') read as terse notes rather than prose.

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 high-complexity mutation with 11 parameters, 8 required, a nested recipe object, no annotations, and no output schema. The description should therefore explain the return shape (a queued validation job id?), failure modes such as hash mismatch or path outside allowed roots, and idempotency behavior, none of which are 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% across 11 parameters, so the description must compensate and largely does not. It explains only the recipe.method constraint and the two hash fields (and references a 'region' that does not appear as a top-level property), leaving batch_id, asset_id, candidate_path, source_attempt, inspected_paths, expected_shape_attempt, idempotency_key, and diagnosis entirely 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 names a specific action and object: staging an allowed-root edited GLB immutably and running the repair gates on it. That is clearly a submission/validation-queue operation, not a generation or status tool, so it is distinguishable from most siblings. It stops short of naming create_shape_repair_attempt, the closest sibling, so the boundary between the two is left implicit.

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?

Prerequisites are stated concretely (recipe.method=import_candidate, an explicit region, exact candidate/source SHA-256 values), which tells the agent when the call is legal. The line 'it does not accept the candidate' signals a boundary, but no alternative tool is named for the acceptance step, and no guidance distinguishes this from create_shape_repair_attempt.

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