addresses_getWhale

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

No annotations are provided, so the description carries full burden. It explains the output (returns addresses and cast commands) but does not disclose behavioral traits such as whether the tool is read-only, idempotent, or requires specific permissions. The description implies it is safe (no destructive actions mentioned), but this is not explicit. Given the lack of annotations, a score of 3 is appropriate as the description is adequate but not fully transparent.

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 well-structured with clear sections (WHEN TO USE, returns, example flow). It is reasonably concise, though the example flow could be shortened without losing clarity. Every sentence adds value, and the structure aids quick understanding.

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 has no output schema, the description adequately explains return values (protocol contract addresses, cast commands). It provides enough context for an AI agent to understand how to use the output. However, it could be more complete by specifying the exact response format or field names. Still, it is sufficient for most use cases.

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?

The input schema covers all 4 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by explaining the context of 'amount' (smallest unit) and 'recipient' (included in funding commands), and the example flow illustrates how parameters are used together. This goes beyond mere schema repetition, earning a 4.

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: getting whale addresses for funding test wallets. It uses specific verbs ('get', 'returns') and resources ('whale addresses', 'protocol contract addresses'), and the example flow reinforces the purpose. It naturally distinguishes from siblings like addresses_listWhales by emphasizing the use case of funding test wallets.

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 a clear 'WHEN TO USE' section with a concrete scenario ('users need tokens to test DeFi apps'). It also explains why protocol contracts are preferred. However, it lacks explicit when-not-to-use guidance or comparison to sibling tools like addresses_listWhales or addresses_getToken, which could help the agent choose between them.

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