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

With no annotations, the description carries the full burden and discloses key behaviors: 'display only, no action is taken' (repeated), 'No action is taken,' and the precedence of mnemonic over private key. However, it is fragmented and truncates mid-sentence ('The suppo'), which slightly reduces clarity.

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 poorly structured: the first sentence is duplicated verbatim, there is an incomplete phrase ('The suppo'), and the @param block is appended without formatting. While not overly long, the redundancy and truncation undermine conciseness and readability.

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 4-parameter tool with an output schema, the description covers the essential purpose, safety (no action), and parameter usage. However, it omits details like accepted blockchain_fk values or error conditions, and the truncation leaves a gap. It is adequate but not complete.

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 description coverage is 0%, so the description must compensate. It includes @param lines that add valuable details: api_key is 'allocated to your application', private_key must be 'urlencoded', and mnemonic keywords are 'separated by a space'. It also clarifies that exactly one of mnemonic/private_key is required. This goes beyond the bare schema definitions.

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 recovers a blockchain wallet from a private key or mnemonic, with the caveat 'display only, no action is taken.' The verb 'recovers' and resource 'blockchain wallet' are specific, but it does not differentiate from sibling tools like access_recover or wallet_mnemonic.

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 explicit usage guidance: 'The order of recover is to use the mnemonic first, private key second. One or the other must be provided.' This clarifies when to use which parameter, but it does not mention when to avoid this tool or name alternatives.

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