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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false. The description adds meaningful context beyond them: the operation is inherently mutual, creating a friendship and reciprocal favorites on the counterparty's side, so the agent understands this writes to another user's data. It still omits failure modes (expired/used token) and whether the invite is consumed one-time despite idempotentHint.

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?

A single front-loaded sentence with no filler: verb, input forms, and outcome. Nothing restates the tool name or wastes tokens.

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 two-parameter mutation with no output schema, the description covers the core action and its mutual side effect. Gaps remain around the undocumented `note` parameter, whether authentication is required, and what the agent should expect on an invalid or already-redeemed token.

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 0%, so the description must compensate. It does this well for `token`, revealing the 'agti_...' prefix and that a whole pasted invite prompt is accepted, but the optional `note` parameter is never mentioned and its purpose (message to the friend? internal memo?) is left entirely undefined.

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 names a specific verb ('Redeem') and resource ('invite token'), plus the resulting state change ('mutual friendship and reciprocal favorites'). This clearly separates it from the sibling friend_invite, which evidently issues invites rather than consuming them.

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?

Usage is implied by 'Redeem a friend's ... invite token', and the parenthetical helpfully notes a full pasted invite prompt is also acceptable. However, there is no explicit when-to-use/when-not guidance, no mention of prerequisites (must be signed in?), and no naming of alternatives or error conditions such as expired/invalid tokens.

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