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

Annotations declare non-read-only, non-destructive, non-idempotent, open-world, and the description adds the key side effect that admins are notified. It omits what a duplicate call does (non-idempotent suggests duplicate reports), whether offline email delivery is involved (open-world), and whether a report record is created that shows up in list_wrong_assignment_reports.

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?

One sentence, zero waste, with the actor and condition front-loaded. It is arguably under-specified rather than bloated, but it respects the reader's budget.

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 non-idempotent write tool with an open-world notification side effect and no output schema, the description should say what the caller gets back and what happens downstream. As written, an agent knows what the tool does but not the consequences or follow-up (e.g., tracking via list_wrong_assignment_reports).

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%: bookingUid and correctAssignee are documented in the schema, but additionalNotes is required with no schema description and the tool description gives no hint about what it should contain. Baseline for this coverage is 3 since the schema carries most of the burden, but the description does nothing to close the remaining 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?

States a specific action (notify a team's admins) applied to a specific situation (a round-robin booking assigned to the wrong host), which is meaningfully clearer than the bare name. It does not, however, distinguish itself from near-siblings such as reassign_booking, reassign_booking_to_host, or update_wrong_assignment_report, so an agent must infer that this reports rather than fixes.

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 triggering condition is implied well enough ('a round-robin booking was assigned to the wrong host'), but nothing says when to prefer this over actually reassigning the booking, nor whether it is meant for cases the caller cannot fix directly. No exclusions or prerequisites are given.

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