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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely useful context beyond them: external publication, durable execution, the partial-failure policy that completed items are not rolled back, deterministic idempotency-key derivation on omitted keys, and the rule that a write with multiple authorised seats must pass seatId/seatName on that exact call. These are real operational constraints an agent would otherwise get wrong.

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 useful constraints (idempotency, seat, partial failure) are buried after a wall of operational metadata, and roughly half the text is cross-tool boilerplate about how to format user-facing responses and never show raw JSON. That boilerplate does not help an agent invoke this specific tool and dilutes the front-loaded 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 need not be described, but for a 21-parameter external-publishing mutation the description leaves the core purpose unstated and most parameter meanings unexplained. It is complete on orchestration/response-handling policy and incomplete on what the tool does and what its arguments mean.

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 21 parameters, so the description carries the full burden, but it only explains idempotencyKey and the seatId/seatName write requirement. The remaining high-value parameters (force, dryRun, approvalId, targetMarkets/contentLocales language resolution fields, marketContext, languageVariantGroupId) are undocumented in both schema and description.

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 opens by restating the name ('retraffick creative') and then gives classification metadata ('publishes externally', 'Execution: durable') rather than a verb+resource statement of what the tool actually does. It never distinguishes itself from close siblings such as traffick_creative, retraffick_flight, or preview_trafficking_output, so an agent cannot tell which trafficking variant to pick from the description alone.

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?

It enumerates mutation modes (validate_only, preview_only, execute) which hints at mode selection, but nowhere states when to choose this tool over traffick_creative or retraffick_flight, nor any prerequisites beyond the seat requirement. The paragraph about how to phrase responses to the user is presentation guidance, not tool-selection guidance.

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