validate_mnemonic

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety behavior is covered. The description adds meaningful behavioral context beyond annotations: it works offline and performs three specific checks (word count, wordlist, checksum), which helps an agent predict the tool's behavior.

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 short, front-loaded with the core purpose, and every line adds value. The 'Args' section is compact and directly supplements the schema without unnecessary filler.

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 one-parameter validator with an output schema and annotations already covering side effects, the description is complete: it states the exact validation scope, offline operation, and argument format. No critical information is missing.

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 explain the parameter. It does by defining 'mnemonic' as 'the space-separated seed phrase to check,' which adds format and role beyond the raw schema field name.

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 uses a specific verb ('Check') with a concrete resource ('BIP-39 phrase') and explicitly names the validation dimensions: word count, wordlist, and checksum. This clearly distinguishes it from siblings like generate_mnemonic and validate_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 description provides useful usage context by stating 'Works offline' and by specifying exactly what kind of phrase it validates, so an agent can infer when to choose this tool. It does not explicitly name alternatives or state when not to use it, but this is straightforward for a one-purpose validator.

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