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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable behavioral traits beyond these: it returns a specific JSON structure with a live countdown (expires_in_seconds), lists the statuses, and explicitly states it never exposes the claim-code secret. This adds contextual detail beyond what annotations provide.

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 description is concise and well-structured. The first sentence states the purpose, followed by lookup methods, then the output fields. It front-loads the key information and avoids unnecessary fluff. The second sentence is a bit dense but organized as a list of fields, making it easy to scan.

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?

Given the tool's simplicity, the annotations covering safety, and the existence of an output schema, the description is sufficiently complete. It tells the agent how to look up status (by claim_id or recipient), what fields to expect, and includes a security note. The only gap is the undocumented caller_id parameter, but this is minor given the tool's overall clarity.

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 must compensate for parameter meanings. It explains claim_id as 'the send id', recipient as 'X handle', and sender_wallet as scoping for a recipient lookup. However, it does not explain caller_id at all, leaving one of four parameters undocumented. The description partially compensates but is not complete.

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 clearly states the tool's purpose: 'Sender-facing claim status of a social send (FREE read).' It names the specific resource (social send) and the operation (check claim status), and differentiates from siblings by specifying the lookup methods (claim_id or recipient) and the output fields. It also adds a security constraint (never exposes claim-code secret), making it unambiguous.

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 description provides clear context for when to use the tool: it is sender-facing and a free read, suitable for looking up claim status. It explains the two primary lookup methods (claim_id or recipient) and optional scoping by sender_wallet. However, it does not explicitly mention alternatives or when not to use it vs. sibling tools like claim_status or get_social_sends, so 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.