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

Annotations already flag destructive=true, idempotent=false and non-read-only, but the description adds real semantics the annotations cannot: the blast radius is limited to one campaign's outreach and the contact is explicitly not suppressed. It also discloses optimistic concurrency behavior tied to expected_revision and the required re-read after a conflict, which is meaningful for a non-idempotent 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 short sentences, front-loaded with the action and its consequences before the concurrency caveat. The pronoun in "It is tied to the revision" is slightly ambiguous, but otherwise there is no wasted wording.

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, non-idempotent mutation with concurrency control and no output schema, the description covers side effects, non-suppression scope, and conflict handling. It stops short of stating whether a skip can be reversed (restoreCampaignDrafts exists as a sibling) or what a conflict error looks like, which would round it out.

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 description coverage is 0%, so the description must carry the parameter burden. It explains expected_revision well (must be the revision that was read, re-read on conflict) but leaves messageId and the params/body nesting entirely implicit — the agent must guess that messageId identifies the draft being skipped.

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?

"Skips one draft in Review" gives a specific verb, resource, cardinality and location, which separates it from bulkSkipMessages. It does not differentiate itself from adjacent single-message operations like denyMessage or returnQueuedMessageToReview, so the agent still has to infer which terminal action applies.

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 consequences (no further outreach from this campaign, no suppression) implicitly tell the agent when this action is appropriate. There is no explicit when-not guidance, no named alternative, and no statement of prerequisites such as the message needing to be in Review.

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