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

The description goes far beyond the annotations, disclosing external publication, durable execution, a partial failure policy (completed_items_not_rolled_back), mutation modes, a derived idempotency key mechanism, and the requirement to provide seatId/seatName on mutation when multiple seats are authorized. It also explains the nature of the returned JSON as internal state and provides response-handling directives. These are substantial behavioral disclosures not present in the annotations, and there is no contradiction with the annotation hints.

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 moderately sized, front-loaded with the core purpose, and contains valuable operational details. However, it is a dense block of text without visual structuring (bullets or sections), and several sentences about response formatting ('Never display raw JSON', 'Mention IDs only when useful', 'Prefer concise, human language') could be condensed or relocated without loss of meaning. It reads more like a paragraph of instructions than a scannable tool description.

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 tool is complex (9 params, mutation modes, external side effects) and the description covers important behavioral aspects like durability, failure policy, idempotency, and seat handling, which is good. However, it lacks fundamental semantic context about what 'trafficking' does, what the required parameters refer to (account, flight, creative), and how optional parameters like force, dryRun, and approvalId influence execution. With no output schema summary needed (since an output schema exists), the description still leaves an agent uncertain about preconditions, parameter dependencies, and the exact nature of the operation.

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 full burden for parameter explanations. It does clarify the idempotencyKey parameter (deterministic retry if omitted) and the seatId/seatName requirement for mutations, but it leaves accountId, flightId, creativeId, force, dryRun, and approvalId completely unexplained. The mutation modes hint at validate_only, preview_only, and execute behavior but do not map to specific parameters like dryRun. A substantial portion of the input schema remains semantically opaque to an agent.

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 tool's primary action as 'traffick creative' and clarifies the high-level effect with 'Classification: publishes externally.' This distinguishes it from pure read tools and provides a clear verb+resource pairing. However, it does not fully define what 'trafficking' entails in terms of the creative-flight-adserver relationship, and it does not explicitly differentiate from sibling tools like traffick_flight or retraffick_creative.

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 provides some operational context (mutation modes, seat requirements, idempotency behavior) but gives no explicit guidance on when to use this tool over alternatives. It does not mention when to prefer traffick_creative versus traffick_flight, retraffick_creative, or other related tools. The only implicit signal is that it is a mutation that publishes externally, but no exclusions or alternative recommendations are offered.

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