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

Goes well beyond the destructiveHint=true annotation: it discloses that cancellation is irreversible and does not roll back completed steps, that a run mid-step returns 409 (a retryable conflict, not a hard failure), and that runs act as the key owner but never above the key's permission level and die if the key is revoked or downgraded. That permission-ceiling and revocation behavior is genuinely non-obvious and high-value.

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?

Structurally poor: it opens with a truncated return-value fragment, embeds a raw HTTP path mid-paragraph, and states the 409 rule twice nearly verbatim. The middle passage about what workflow runs can generally do (webhooks, functions, record mutations) is background about the resource rather than about the cancel action, and dilutes the actionable content.

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 destructive mutation with no output schema, the description covers what an agent needs: irreversibility, the 409 retry condition, space targeting, and permission scoping. Only the runId provenance and a confirmation expectation for such an irreversible action are missing, which keeps it short of a 5.

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 50%: targetSpaceId already documents the auth_verify/multi-space flow in the schema, so the description largely repeats it. It does add value for the undocumented runId by exposing the path template POST /api/v1/workflow-runs/{runId}/cancel, but gives no guidance on runId format or where to obtain it (e.g., workflows_list).

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 eventually states a clear verb+resource and precise semantics: "Cancelling stops the run for good and does not undo steps that already ran." However, it never contrasts the tool against siblings like workflows_decide or workflows_start, and the very first sentence ("The cancelled run.") is a stranded response fragment that obscures rather than announces the purpose.

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 operational routing: for multi-space accounts call auth_verify, ask the user which space, then pass targetSpaceId; and on a 409 retry after the running step finishes. What it never says is when to choose cancel versus workflows_decide or workflows_start, which is the primary selection decision an agent faces.

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