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

Beyond the annotations (readOnly false, idempotent true, destructive false), the description discloses billable AI usage, synchronous execution, mutation modes, partial failure policy ('completed_items_not_rolled_back'), and the internal state nature of the returned JSON. It also explains idempotency key behavior. These are significant behavioral details not available in 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 front-loaded with a clear purpose statement, but then becomes a dense block covering response formatting and idempotency. While this information is useful, it is verbose and partially redundant (deprecation appears in both title and description). The structure is list-like but could be more concise.

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 substantial behavioral context (modes, failure policy, response handling) and the output schema exists, so return values are covered. However, it fails to give any guidance on the tool's required parameters, especially the nested creative object, which is a notable gap for correct invocation.

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?

The description provides no explanation of the input schema parameters. Schema description coverage is 0%, and the only parameter mentioned is idempotencyKey, which is not even in the schema. Required parameters such as brand, format, objective, and creative are completely unaddressed, leaving the agent to rely on parameter names alone.

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 with a specific action: 'QA a creative for launch readiness with actionable issues, certification evidence, and next steps.' It clearly names the resource (creative) and the purpose (launch readiness). It also distinguishes itself from the sibling tool by stating 'Deprecated alias for qa_creative,' which resolves ambiguity.

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 gives explicit usage context: 'before preview, revision, or trafficking.' It also signals to prefer a different tool by labeling itself as a deprecated alias for qa_creative. Additional constraints like 'Task support: forbidden' and mutation modes further clarify when and how it should be invoked.

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