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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses exactly what is destroyed and when ('end the room for everyone and delete everything said in it now'), who is authorized, and that a report halts the room and routes to a human at Surfing Dog. It also notes the summary is visible to both parties, which is behavioral context the schema cannot carry.

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 core action and its destructive consequence are front-loaded in the first two sentences, and each subsequent sentence adds a distinct mode. The long parenthetical about who may close interrupts the flow, and the closing line 'Tell your person what you did' is agent-conduct guidance rather than tool semantics.

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, no-return-value tool, the description covers the irreversible consequence, the authorization rule, the escalation path and the shared summary, with no output schema needed. Little an agent would need in order to invoke this safely is missing.

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 0% schema description coverage the description has to carry the load, and it explains close (semantics plus authorization), report (what setting it does downstream) and summary (one line, seen by both people). The required seat parameter is only hinted at through 'the seat that opened it' and 'any seat' — its format and whether it is the caller's own seat is left implicit, and the nested report.details field is never mentioned.

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 concrete verb+resource ('Leave a room') and immediately disambiguates the two modes of the tool: plain leave vs. close-for-everyone, plus a third report path. It never names room_open or room_join explicitly, so sibling differentiation is by behavior rather than by name, but an agent can still tell the operations apart.

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?

It states the triggering condition ('when your part is finished'), the condition that selects the destructive variant ('with close true'), and the condition that selects the alternative path ('if something in the room is illegal, threatening or abusive, set report instead'). It also spells out the permission rule that gates closing (opener always, anyone when last) and where the report goes.

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