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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety posture is known; the description still adds real value by stating the blast radius ('Published likes and comments remain') and the retry/ambiguity behaviour ('an ambiguous previous send retains its reconciliation owner'). The latter is phrased opaquely, which keeps it from a 5.

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 dense sentences that front-load the state change and then the residual effects; every clause carries information. The only waste is the opening line repeating the tool title/name verbatim.

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 an output schema (so return values need no explanation) and annotations covering the safety profile, the description covers what is stopped, what survives, and how ambiguity is handled. It leaves unclear what happens to a boost that has not yet sent anything and whether the call can be repeated after failure, but the core is covered.

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 description says nothing about the single nested `path.id` argument. The schema itself does describe the id as 'ID returned by the corresponding Post Boost read or create operation', so an agent is not blind, but the description contributes no additional meaning about where that ID comes from or whether other identifiers are accepted.

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 pairs a specific verb ('cancel'/'Stop new actions') with a specific resource ('this workspace's boost'), and adds scope via 'Stop new actions' rather than implying deletion. It does not name any sibling (e.g. getPostBoost, listPostBoosts) to differentiate, which keeps it just below a 5.

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: an agent can infer this is the tool to call when it wants to halt an in-flight boost, but there is no explicit 'use this instead of X' or precondition statement. 'Stop new actions on this workspace's boost' is the only contextual cue, and the workspace scoping is a useful but partial hint.

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