radiant_restore_wallet

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

The description adds useful behavioral detail by stating that the mnemonic checksum is validated and the private key is derived via BIP32. However, with no annotations available, it does not disclose whether the restore persists the wallet, overwrites an existing one, or what happens on failure — a meaningful gap for a state-changing wallet 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?

Two tight sentences, front-loaded with the main purpose and no filler. Every clause carries meaning, and the structural balance between what the tool does and how it works is efficient.

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?

Although all parameters are documented, there is no output schema and no annotations, and the description never states whether the restored private key or wallet is returned, stored, or whether restoration can overwrite an existing wallet. For a security-sensitive restore operation, this is a significant completeness gap.

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 100%, so the schema already documents all four parameters. The description reinforces that the mnemonic is BIP39 and the derivation is BIP32, but it does not add materially new parameter-specific semantics beyond what the schema provides.

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 opens with a specific verb and resource: 'Restore a Radiant wallet from a BIP39 mnemonic phrase.' It further clarifies the operation by naming checksum validation and BIP32 derivation, making it easy to distinguish from siblings like radiant_create_wallet and radiant_derive_address.

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 phrase 'Restore... from a BIP39 mnemonic' implies the appropriate use case of recovering an existing wallet, but there is no explicit guidance about when to prefer this over radiant_create_wallet or radiant_derive_address, nor any exclusions or prerequisites.

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