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

Annotations already declare idempotentHint=true and destructiveHint=true, so the description's mention of an idempotent client_id largely restates structured data. More importantly, destructiveHint=true is never explained: nothing says whether claiming replaces an existing canonical assignment, whether it expires, or what happens on a competing claim. The schema's OAuth consent requirement for room_id is also not carried into the description.

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 with the affirmative definition first and the boundary conditions second. No redundant phrasing or filler; every clause carries scope information.

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 4-required-parameter mutation flagged destructive with no output schema and half the parameters undocumented, the description leaves major gaps: claim outcome, conflict/expiry behavior, and prerequisites are all absent. The negative clauses are useful but do not compensate for these omissions.

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 description coverage is only 50%: relay_id and assignment_id have no description anywhere, and the description does not explain their relationship (assignment vs. relay) or format. The only parameter the description names, client_id, is already fully documented in the schema, so no net meaning is added.

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 verb and resource: 'Claims the participant's canonical live relay assignment', which is distinct from read_relay, list_relays and submit_relay_result. The three explicit negations ('does not attest reading, authorize tools or create a turn') further bound the scope, but no sibling is named directly, so differentiation is inferred rather than stated.

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 exclusions ('does not attest reading, authorize tools or create a turn') tell an agent what sibling operations this is not a substitute for, which is real routing value. However, there is no positive when-to-use condition — nothing says the caller must already hold an assignment, or that this precedes submit_relay_result.

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