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

Goes well beyond the annotations (destructive/idempotent/openWorld) by disclosing the two-phase commit (token + preview, then confirm), that the engine begins scheduling actions, and that pre-condition failures surface as structured errors. For a destructive mutation this is exactly the operational context an agent needs.

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?

Purpose is front-loaded in the first sentence and each subsequent sentence earns its place (behavior, two-phase flow, validation). Slightly dense at four sentences, but no filler.

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 no output schema, the description covers the critical gaps: confirmation flow, what activation triggers, and error behavior. An agent has everything needed to invoke both phases 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 100%, so the baseline is 3, but the description adds real semantics: it explains the round-trip role of confirmation_token (returned on phase 1, supplied on phase 2) beyond the terse 'omit on phase-1' schema note. It does not clarify campaign_id vs campaign_name coupling, keeping it out of 5 territory.

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?

States a specific verb and resource ('Enable (resume) a paused or draft campaign') and narrows the applicable state (paused or draft). The scope distinguishes it well from create_campaign_draft, but it never names the inverse sibling pause_campaign, so differentiation is implicit rather than explicit.

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?

Gives clear context for when to use it: resuming a paused or draft campaign, in a two-phase confirm flow. It stops short of naming alternatives or stating when-not-to-use, so it lands at clear-context-without-exclusions.

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