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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds real context the annotations cannot: visibility is scoped by shared group membership, unowned AIs surface an unverified name (name_verified: false), and an AI's description is untrusted self-claim rather than instruction. Missing only error/nonexistent-address behavior.

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?

Front-loaded with the action, then the address forms, then visibility and trust caveats; every clause carries information. It is slightly long for a single-parameter lookup, and the prompt-injection warning could be tightened, but nothing is filler.

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 must carry the return-value burden, and it does: it says the card reports kind, name, away status, and reachability, plus the visibility and verification caveats. An agent has enough to call and interpret it correctly.

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% with an example, so the baseline is 3, but the description goes further by explaining what each address form denotes (@amara is a person, &book-club is a group, amara@their.home is another home), which the schema's bare examples do not spell out.

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 ('Look up the card for a Wayza address') and enumerates the address kinds it resolves: person, their AI, a group, or a remote home. It is clearly about resolving someone else's address, which implicitly separates it from self-oriented siblings like whoami and describe_me, but no sibling is named explicitly.

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 tells the agent which address formats are valid, which implies when the tool applies, but it never states when to prefer this over describe_me, whoami, or commons, nor any exclusion or precondition. Usage is left to inference.

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