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

The description adds substantial behavioral context beyond annotations: mutation modes (validate_only, preview_only, execute), partial failure policy (completed_items_not_rolled_back), idempotency key derivation, and the seatId/seatName requirement for writes when multiple seats are authorised. This is rich disclosure, though the awkward 'Classification: read-only' text conflicts with the write-oriented mutation modes listed.

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 bloated with boilerplate orchestration instructions (assistantSummary guidance, 'never display raw JSON', tone directives) that crowd out the actual tool-specific information. The most important facts – what the tool does and its mutation modes – are buried after a long metadata preamble.

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?

It covers the mutation lifecycle and idempotency/seat requirements, and an output schema exists so return values need not be explained. But with 16 parameters at 0% schema coverage, the description leaves most input semantics undocumented, falling short for a tool of this complexity.

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% with 16 parameters, so the description must compensate. It covers the seatId/seatName requirement and idempotencyKey behavior, which is valuable. But it doesn't explain advertiserId, opportunityId, targetMarket(s), locale fields, or the language variant parameters at all, leaving most of the 16 params undocumented.

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 states a specific verb and resource: 'Create a concise proposed campaign plan from one grounded opportunity.' The title adds the key caveat that studio approval is required before campaign creation, which distinguishes this from launch_creative_campaign or create_campaign. It is clear, though it doesn't explicitly name those siblings.

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 description implies usage ('from one grounded opportunity') and the title notes studio approval is required before actual campaign creation, hinting at the validate/preview/execute mutation modes. However, it never explicitly states when to choose this over run_creative_intelligence, select_world_opportunity_for_campaign, or create_campaign. No explicit when-not or alternative guidance.

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