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

Beyond the destructiveHint annotation, the description discloses concrete effects: it releases the authorized hold, never bills a cancelled job, returns status: cancelled, and cannot operate on terminal jobs. This is exactly the operational context an agent needs before invoking a mutation.

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?

Four tight sentences carry the action, the precondition, the result, and the billing outcome with no redundancy. The most decision-relevant information 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?

For a single-parameter cancellation tool, the description covers the success condition, the failure condition, the return envelope, and the financial consequence. With an output schema present, 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?

Schema coverage is 100%, so the jobId parameter is already documented as 'The job id returned by the submit call.' The description reinforces this by referencing jobId and the submit tool, but adds no new semantic detail beyond the 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 and resource: cancel an Oxylabs LLM job, scoped to queued jobs and addressed by jobId. This clearly distinguishes it from the sibling submit tool post_oxylabs_llm and the retrieval tool get_oxylabs_llm_job.

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 states when the tool applies (queued jobs submitted by post_oxylabs_llm) and when it does not (jobs already in a terminal state). It doesn't name an alternative tool for checking status, but the boundary conditions are explicit enough for correct selection.

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