lookup_user_wallet

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

No annotations, so the description carries the full behavioral burden, yet it does not say whether the lookup requires authentication, what happens when the username does not exist, or whether the wallet is created/hidden. Only the word 'default' hints at behavior (which of a user's wallets is selected), which is not enough for a no-annotation tool.

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. Nothing redundant or wasteful for a simple read tool.

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 read tool with no output schema, the agent still lacks the return shape (wallet address? currency? both), error semantics for unknown usernames, and any auth requirement. The description is adequate as a label but incomplete as a calling contract.

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 both parameters are already documented, establishing a baseline of 3. The description's 'default wallet' phrasing reinforces the optional wallet_currency enum but adds no explanation of how currency changes the result.

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 (look up) and resource (a user's default wallet) scoped to a Blink username, which cleanly separates it from get_wallets (own wallets) and send_to_username. It is clear what it does, though it never explicitly contrasts itself with those siblings.

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?

Usable with a single required username; no explicit when-to-use or when-not, and no named alternatives for cases like resolving another user's wallet versus your own. In a 50-tool family with nearby wallet tools, that omission forces the agent to infer routing.

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