cancel group request

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

Annotations already flag destructive/idempotent, but the description goes well beyond them: it specifies that same-revision replay cannot create a second effect, that there is no automatic retry, that INBOX_FULL rolls back the entire action, and how 409/REQUEST_NOT_FOUND/403/429/401 each behave. Session sourcing (signin tools, accessToken as sessionToken) and the HORIZON_API_KEY dependency are also disclosed.

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?

It is well front-loaded and sectioned (Use when / Not for / Requires / Side effects / Returns / Errors), but the Errors block is bloated, restating 401 and 403 twice with overlapping explanations of token ownership and API-key failure. Several lines could be merged without losing guidance.

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?

With no output schema, the description supplies the return shape ({groups:MyGroupsView, group:GroupView|null}) and its cache implications, so an agent knows what state changes after the call. Combined with the error/reconciliation guidance, nothing needed to invoke this destructive mutation correctly 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?

Schema coverage is 100%, so the baseline is 3; the description nevertheless adds real meaning by explaining where sessionToken comes from and warning that expectedRevision and requestId must come from the reviewed snapshot and never be refreshed after an uncertain response. It does not elaborate on userId/groupId beyond the schema.

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 side-effects line ('Cancels your exact join request') makes the resource and the actor precise: the player withdrawing their own pending join request, not a leader declining someone else's. The opening sentence ('Applies the explicit cancel group request action') is close to a restatement of the name, and no sibling such as horizon_decline_group_request or horizon_cancel_group_invite is named to sharpen the boundary.

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 uses explicit 'Use when' / 'Not for' framing, and the exclusions (don't replace reviewed revisions or requestIds, don't bypass a leader's block, don't auto-retry) are concrete and actionable. The positive trigger ('the player explicitly confirms this group action') is generic, though, and does not tell the agent when to pick this over declining or cancelling an invite.

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