Cancel a draft in progress

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

Adds meaningful context beyond annotations: the cancelled turn remains on the drafting list for 24 hours and can then be retried or dismissed, which tells the agent this cancellation is recoverable rather than final — an important nuance for a tool marked destructiveHint=true. It also discloses required scopes and the idempotency behavior. Missing only details on rate limits or what the response contains, which the output schema covers.

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?

The behavioral explanation is front-loaded in two tight sentences, followed by scannable metadata lines for endpoint, scopes, idempotency, and workspace. The operation/scope boilerplate is somewhat repetitive with the idempotency sentence but each line carries operative 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?

Output schema exists, so return values need not be explained. The description covers the essential gaps for a destructive, idempotent mutation: what it cancels, what it cannot cancel, auth scopes, idempotency handling, and post-cancellation state. Complete enough to call correctly.

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 75%, so the schema already documents most parameters. The description still adds value by explaining that workspaceId/workspaceSlug 'override the default workspace configured by environment' and by tying idempotencyKey to safe retries versus server-generated keys. That reinforces but largely restates what the schema descriptions already say.

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?

Opens with a specific verb and resource: 'Stop the reply Luca is writing for one inbound turn.' An agent can immediately tell this halts an in-flight draft rather than approving, rejecting, or retrying one. It does not explicitly name which sibling (drafting_retry, drafting_dismiss, reject) to use instead, so it stops just short of full differentiation.

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?

States a clear precondition boundary: it works on a 'queued draft that is still pending' and explicitly does NOT apply to an 'approved or sent one.' That exclusion is genuinely useful routing signal. It gives no positive pointer to alternatives for approved/sent drafts, so it falls short of a 5.

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