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

With readOnlyHint=true already supplied, the description adds real value by defining the boundary of the check: format only, not ownership and not memo/tag requirements. That prevents a costly false-positive interpretation where an agent treats a passing validation as proof the address is safe to send to. It does not state how an unknown asset slug is handled or the exact return shape, which keeps it below 5.

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?

Two short sentences, front-loaded with the core check and followed immediately by the scope exclusions. Every clause carries information an agent needs; nothing is restated from the title or schema.

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-only check with no output schema, the description covers purpose and boundaries but never says what comes back: the word 'whether' implies a boolean result but does not confirm it, and error behavior for an unrecognized asset slug is unspecified. An agent can probably call it correctly, yet the return contract is left to inference.

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 50%: 'address' has no description at all and 'asset' only says 'asset slug'. The description mentions both an address and an asset but adds no format detail for either, such as expected address encoding or the slug convention. With half the parameters undocumented, the description neither compensates nor is obligated to, so the baseline 3 fits.

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 states a specific check on a specific resource: format validity of an address for a given asset. The second sentence sharply bounds the scope by naming two things it does not verify (ownership, exchange memo), which lets an agent separate this from any transfer-related sibling. It stops short of an explicit verb like 'validates and returns a boolean', but the intent is 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?

Usage is implied rather than stated: an agent can infer this is a pre-flight check before sending funds, and the explicit exclusions ('does not check who owns it or whether an exchange needs a memo') tell it what this tool cannot answer. There is no positive guidance about when to call it or what to do with the result, and none of the swap/quote siblings are named as alternatives.

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