Leave Match

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

Annotations already declare destructive/openWorld/idempotent, and the description adds substantive context beyond them: 'One HTTP attempt', 'Active leave forfeits without selecting a winner', creator-only lobby cancel, the durable Inbox notice that does not undo a committed move, plus the 429 rate-limit and HORIZON_API_KEY/auth failure modes. Nothing here contradicts the annotations.

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 Use when / Not for / Requires / Side effects / Returns / Errors skeleton is well front-loaded, but the block is long and telegraphed as fragmented clauses. Several segments (Start requires the creator and every joined UUID, Turn requires the current unexpired actor, Timeout advances only one turn) describe actions this tool's schema cannot perform, which dilutes rather than focuses the definition.

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 mutation tool with no output schema, the description covers return shape, auth prerequisites, key error codes and rate limiting, so an agent has enough to call it correctly. The residual gap is resolving how this tool relates to the closely-named match siblings.

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 100%, so the baseline is 3; the description goes beyond the schema by spelling out that sessionToken must be the accessToken from horizon_signin_email/horizon_signin_anonymous and that the 403 case means the userId must match the token owner. It adds interpretation rather than format detail, earning a 4 but not a 5.

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 opening 'Executes leave match under the exact original revision' is close to restating the name, and the body then describes start/turn/timeout/lobby-cancel semantics that the 4-parameter schema cannot express. The verb+resource is identifiable, but an agent cannot cleanly tell what this tool does that horizon_cancel_match or horizon_submit_match_turn do not.

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?

'Use when: explicit asynchronous multiplayer actions after reading horizon://docs/matches' and an explicit 'Not for: automatic polling, page traversal, timeout progression...' give real when/when-not guidance, and it names horizon_get_matches/horizon_get_match as the reconcile path. It does not address the nearest siblings (horizon_cancel_match, horizon_submit_match_turn, horizon_advance_match_timeout), which is why it falls short of a 5.

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