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

Goes well past the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false). It discloses the partial-failure policy (completed_items_not_rolled_back), the three mutation modes, deterministic retry-key derivation, and the multi-seat authorisation precondition  exactly the kind of write-time behavior an agent cannot get from structured fields.

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?

Front-loaded and the field-mapping sentence is the most valuable part, but the block is long and repeats the title verbatim at the start. A large share of the text is response-formatting policy (assistantSummary, never display raw JSON) that is orchestration guidance rather than tool-invocation guidance, diluting the signal.

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?

An output schema exists, so return values are adequately covered elsewhere, and the annotations plus description cover the safety/idempotency profile well. The gap is on the input side: for a 20-parameter, deeply nested write with 0% schema description coverage, the description accounts for roughly a third of the parameters and says nothing about optional locale/market-context plumbing or versioning.

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% across 20 parameters, so the description must carry the load. It does map natural-language phrasing to concrete fields (calledcampaignName, funnel/awareness termsfunnelStage, impression goalstargetImpressions, KPI labelsprimaryKpi/secondaryKpi) and explains idempotencyKey and seatId/seatName, but leaves many top-level parameters such as accountId, approvalId, expectedVersion, marketContext, and the locale fields entirely 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?

States a specific verb and resource (Create a Studio campaign) and adds that all campaign fields must be nested inside the `campaign` object, which is a real structural instruction. It does not differentiate from close siblings such as `launch_creative_campaign`, `leanr_build_campaign_creative_set`, or `leanriq_campaign_builder`, so an agent must still infer which creation path 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?

Provides genuine operational context: mutation modes (validate_only, preview_only, execute), the requirement that seatId/seatName be passed on the exact write call when multiple seats are authorised, and the fact that idempotencyKey is auto-derived on omission. However, it never says when to prefer this tool over the campaign-building siblings, which is the main routing decision an agent faces here.

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