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

The description discloses substantial behavioral detail beyond the annotations: mutation modes (validate_only, preview_only, execute), partial failure policy (completed_items_not_rolled_back), idempotency key derivation when omitted, and the seat requirement on mutations. These are valuable context that annotations alone do not provide. 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 verbose and mixes tool-specific behavior with generic response guidelines (e.g., 'Use assistantSummary first', 'Never display raw JSON'). The redundant opening 'create advertiser' restates the tool name. Many sentences are operational policy that applies to all tools, making the description bloated and harder to scan.

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?

The description provides rich operational context (mutation modes, partial failure, idempotency, seat requirements) but lacks domain context about what an advertiser is in the Studio system and does not explain how this tool relates to similar sibling tools. The output schema exists, so return values are covered, but the description is incomplete for a tool with this level of 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 coverage is 0%, so the description must compensate. It adds meaning for idempotencyKey (omission behavior) and seatId/seatName (conditional requirement), but leaves other parameters like accountId, advertiser, approvalId, expectedVersion, and dryRun unexplained. The schema itself provides structure, but the description only partially compensates for the lack of semantic guidance.

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 the core action clearly: 'create advertiser' and 'writes to Studio'. This makes the tool's purpose unambiguous and distinct from update/advertiser or archive_advertiser by the verb 'create'. However, it does not differentiate from leanriq_resolve_or_provision_advertiser, which may also create an advertiser.

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?

There is no explicit guidance on when to use this tool versus other advertiser-related tools like update_advertiser or resolve_or_provision_advertiser. The description provides some operational constraints (e.g., seatId/seatName required when multiple seats are authorized) but does not address tool selection or prerequisites beyond that.

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