cancel_assembly_job

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

With no annotations, the description carries the full burden and does so well: it discloses that accepted=true is a request rather than proof of cancellation, that running OCCT calls cannot be interrupted, that cancellation is refused once committing starts, and that rollback semantics apply to running mutations. These are non-obvious operational traits an agent would otherwise get wrong.

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 dense sentences, each carrying distinct information, with the primary action stated first and the caveats after. The line-broken formatting is slightly awkward but nothing is redundant.

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 mutation tool with no annotations and no output schema, the description closes the critical gaps: the accepted-not-cancelled contract, the refusal window, and polling for terminal state. Only the source of job_id and any error shape are left unstated.

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 single parameter job_id is undocumented in both schema and description. The description implies a job identity that distinguishes queued from running work but never says where a job_id comes from or what form it takes.

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 (cancel) and resource (assembly job) and immediately splits into two modes: discarding queued jobs versus safe-point cancellation with rollback for running mutations. It does not name a sibling tool, so the distinction from get_assembly_job / get_async_status must be inferred rather than read.

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

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

Gives usable conditions: applies to queued jobs and to running mutations via safe-point cancellation, and is refused once committing begins. It stops short of pointing at the follow-up tool for polling terminal state, leaving the agent to guess among the many get_* siblings.

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