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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, and the last sentence merely restates idempotency in prose, adding no new information. The draft-only rejection rule is genuine added behavior, but the destructiveHint is never explained — the body's required fields (name, audience_snapshot_id, allowed_account_ids, daily_unique_contact_cap) suggest a full replacement of settings, yet the description never says whether omitted fields are wiped or preserved or whether changes are revertible.

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?

Three short sentences, front-loaded with the capability before the constraint. Slightly wasteful in that the idempotency sentence duplicates an annotation already present, but nothing else is padding.

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?

This is a highly complex mutation with deep nested objects, 0% schema description coverage and no output schema. The description omits the replace-vs-merge semantics, what a successful response contains, and what happens on validation failure, so an agent cannot call it correctly without reverse-engineering the schema.

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 load, and it does map several body concepts to real fields (name, audience, ICP, goal, senders, contact limits, sequence). However, it says nothing about the two top-level parameters' roles — that params.id is the campaign UUID and body is a required, closed object — and large nested areas (advanced_settings, plays structure, icp_profile_overrides, campaign_product) get no semantic hints at all.

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 gives a specific verb plus resource ("Changes a draft campaign's settings") and enumerates the affected areas: name, audience, ICP, goal, senders, contact limits and sequence. It doesn't name any sibling such as renameCampaign or updateIcpDraft, so an agent still has to infer from the sibling list which tool to prefer for a name-only change, but the core purpose is unambiguous.

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?

One useful gating condition is stated: "Only drafts can be updated; launched campaigns are rejected." That tells the agent when the call will fail, but gives no positive guidance on when to choose this tool over renameCampaign, createCampaign, discardCampaign or restoreCampaignDrafts, and no prerequisites (ownership, permission, draft state check).

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