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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds useful generic behavioral context about mutation modes (validate_only, preview_only, execute), partial failure policy, and the deterministic idempotency-key derivation. However, it does not disclose delete-specific side effects such as whether the action is reversible or how it affects related campaigns or creatives.

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 long but front-loads a tautology and then spends most of its length on generic orchestration guidance (e.g., 'Use assistantSummary first', 'Never display raw JSON') that is unrelated to this tool. This boilerplate inflates token count and is not appropriately sized for the tool's purpose.

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?

For a destructive tool with 12 parameters and no parameter descriptions, the description omits tool-specific behavior: what deletion does, prerequisites, effect on associated entities, and reversibility. The generic mutation modes and failure policy provide structural context, but the agent is left without the essential information needed to safely invoke delete_flight.

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?

With 12 parameters and 0% schema description coverage, the description must compensate, but it only explains idempotencyKey and the seatId/seatName requirement. It does not clarify the roles of flightId, accountId, dryRun, expectedVersion, approvalId, or the various resource IDs. Most parameter meanings remain opaque.

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 begins with 'delete flight', which is identical to the tool name and title, providing no additional specificity. It does not explain what deleting a flight entails or distinguish it from sibling tools like archive_flight or validate_flight. The rest of the text is generic mutation boilerplate rather than a purpose statement.

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 guidance on when to use this tool versus alternatives such as archive_flight or update_flight. The seat and idempotency rules are generic to all mutations and do not help an agent decide whether deletion is appropriate for a given task. No exclusions or alternatives are mentioned.

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