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

Annotations already declare readOnly=true, non-idempotent, closed-world, non-destructive. The description adds real context beyond them: crypto randomness with no seed (explaining why idempotentHint is false), no network, no stored state, and hard limits (64 KB input, 1 s per call, 1 MB result). Some lines merely restate the annotations, and there is no note on what happens with conflicting inputs (e.g. exclude removing an entire chosen set).

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 Spanish block is front-loaded and scannable with labeled segments (Cuándo / No para / Efectos / Límites), which is good. But the English half is truncated into a pointer ("[EN completo / full EN: inputSchema.description]"), which is padding rather than content, and the mismatched "Cuándo" sentence about decoding embedded fields wastes a slot.

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?

An output schema exists, so return values need not be spelled out, yet the description usefully previews that pool size and entropy bits are reported. All parameters are schema-documented and operational limits are stated. The missing piece is behavior on degenerate configurations (all sets disabled, or exclusions that empty the pool), which for a 10-param generator would be worth one clause.

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 every one of the 10 parameters is already documented with defaults and bounds; baseline is 3. The description adds only marginal semantic value on top ("at least one character from each set" mirrors require_each, ambiguous removal and exclusions mirror their own params) and says nothing new about count, length, or symbol_set interaction.

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?

States a specific verb and resource ("Genera contraseñas aleatorias") plus the mechanism (character sets, exclusions, ambiguous-character removal) and the reported outputs (pool size, entropy bits). The sibling distinction from random-token is explicit. However, the "Cuándo" line calls the output "un identificador" and mentions "leer los campos que lleva dentro" (decoding embedded fields), boilerplate that does not fit a password generator and slightly muddies what the tool produces.

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?

"No para: generar un token aleatorio de 1 a 256 bytes... (random-token)" names an alternative and the condition that selects it, which is exactly the discriminator an agent needs among the random/nanoid/uuid siblings. It gives no exclusion against nanoid, uuid-v4, or idempotency-key, so the routing is clear but not exhaustive.

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