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

Annotations already declare destructive=true, idempotent=true and non-readOnly, so the safety profile is covered; the description goes further by disclosing the billing model (settle consumed work, refund the remainder) and the return contract (first line reports tokens and credits used). The only real gap is whether cancellation is immediate or graceful and what happens to partial results.

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 tight sentences, cost signal front-loaded, behavior second, output-handling instruction last. Nothing is padded and the most decision-relevant fact ("Free") leads.

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, no-output-schema tool the description does the heavy lifting: it compensates for the missing output schema by telling the agent what the first line of the response contains and to surface it. It is only incomplete on the parameter itself and on the mechanics of cancellation.

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 job_id — it neither explains where to obtain the ID nor what happens with an invalid or already-finished job. The regex pattern makes the ID format self-documenting, which is the only thing keeping this above a 1.

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?

"Stop the job and settle consumed work, refunding the remainder" gives a specific verb (stop/cancel) plus the resource (job) and even the financial consequence, which cleanly separates it from the retrieval siblings get_job_status and get_job_result. It stops short of naming those siblings, so an agent must infer the distinction rather than being routed 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?

"Free" is a useful selection signal (no credit cost to aborting) and implies you cancel a job you no longer want, but there is no explicit when-to-use vs. when-to-poll guidance against get_job_status/get_job_result. Usage is only implied, not stated.

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