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

Annotations only convey readOnlyHint=false, openWorldHint=true, destructiveHint=true. The description adds substantial behavioral context beyond that: it mutates live channel state (WARNING), which validates destructiveHint; it discloses the async propagation delay and instructs verification via search_experiments; it reveals the conditional requires_confirmation flow for budget-group impact; and it states preconditions (only pause active experiments, only restart paused ones). No contradiction with annotations.

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 description is long but well-organized into labeled sections (KEYWORDS, WHEN TO USE, SCOPE, ACTIONS, WORKFLOW, VALIDATION, CONFIRMATION FLOW, WARNINGS), and the core purpose is front-loaded in the first sentence. The KEYWORDS list is somewhat redundant with the WHEN TO USE section, and the WORKFLOW partially restates ACTIONS, but these repetitions serve reinforcement and are not 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 4-parameter tool with no output schema, the description covers preconditions, side effects, async behavior, the confirmation sub-flow, and how to verify results. The only notable gap is the precise success response shape (e.g., what status values a successful pause returns), though the requires_confirmation status and budgetImpact field are already disclosed.

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 semantic value: the ACTIONs section defines what 'pause' and 'restart' actually do (stop ad serving/budget spend vs. resume), the RESTART BUDGET CONFIRMATION FLOW explains when and how confirm_budget_impact must be set, and the workflow maps experiment_id to the experimentId field returned by search_experiments. Only auto_pause_ignore_historical_data gets light treatment, though its schema description is adequate.

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 opening sentence uses a specific verb+resource pair ('Pause or restart a whole experiment') and defines the resource precisely ('a launched channel campaign inside a wizard campaign'). The SCOPE section explicitly distinguishes this tool from pause_experiment_keyword/restart_experiment_keyword (keyword-level) and manage_campaign (wizard-campaign-level), so an agent can disambiguate without opening schemas.

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 WHEN TO USE section lists concrete user-query patterns ('pause experiment X', 'stop the LinkedIn experiment'), and SCOPE names the alternatives with exact conditions for when they apply. The WORKFLOW section gives an explicit call sequence via search_experiments first, which is actionable guidance an agent can follow directly.

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