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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds that a ready-to-read summary is returned in `say`, which is useful response context, but it omits what actually happens to the application on retry vs dismiss and any auth/permission requirements.

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?

Two tight sentences, front-loaded with purpose, then the action vocabulary, then a note on the response field. Everything is roughly load-bearing, though the parenthesis '(after answering)' is cryptic and costs a little precision.

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 3-parameter mutation tool with no output schema, the description covers the action vocabulary and mentions the `say` response field, which is adequate. It still leaves the escalation lifecycle (how escalations arise, relationship to list_escalations/prepare_application) and the confirmation-token flow implicit.

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 67%, and the one undocumented parameter (`action`, no schema description, no enum) is fully enumerated and glossed in the description. The meaning of took_over ('they finished it themselves') and the ordering note for retry adds real value the schema lacks; only the terse '(after answering)' leaves a gap.

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 verb 'deal with' is vague, but the three action values (retry, took_over, dismiss) pin down that this resolves a stopped application/escalation. It never mentions the sibling list_escalations or distinguishes itself from stop_application, so the agent must infer the relationship from the name 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?

Each action value implicitly describes a scenario and 'retry (after answering)' signals a prerequisite ordering, which is genuine usage context. However, there is no explicit when-to-use guidance, no exclusions, and no pointer to list_escalations as the way to discover what needs resolving.

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