Stop remaining operation steps

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

Annotations already declare the safety profile (not read-only, not destructive, not idempotent), so the description's job is to add nuance — and it does: cancellation is partial, affecting only steps not yet started, while already-dispatched sends cannot be recalled. That is exactly the kind of non-obvious consequence an agent needs, though it says nothing about what happens to the operation record afterwards or whether repeated cancels error.

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, zero filler, with the core behavior first and the important caveat second. Nothing could be removed 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?

An output schema exists, so return values needn't be explained. However, for a mutation tool the definition omits where operation_id comes from and which operation states are actually cancellable (pending vs. completed), leaving a gap an agent will hit on first use.

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 operation_id has 0% schema description coverage and the description says nothing about it — not its format, nor how to obtain a valid value (presumably from tb_operation_list or tb_operation_status). With coverage this low, the description needed to compensate and 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 description uses a clear verb ('Stop') and scopes it to steps not yet started, which is a precise statement of what the cancel operation does. It does not explicitly name the 'operation' resource or differentiate itself from siblings like tb_operation_status or tb_operation_list, leaving that to the name and title.

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: the agent can infer this is the tool to call when a running operation should be abandoned, but no when-to-use condition or alternative (status/list first, restart instead) is stated. The note about already-dispatched sends sketches a boundary of applicability but isn't framed as guidance.

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