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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description still adds genuinely new traits: deterministic output, no network, no stored state, and concrete operational limits (64 KB input, 1 s per call, 1 MB result). Only the "efectos secundarios: ninguno" sentence restates the annotations.

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?

Both the Spanish and English blocks carry identical content, so roughly half the text is duplicated rather than additive, and the trailing truncated pointer "[EN completo / full EN: inputSchema.description]" is awkward. The structure is front-loaded (purpose → when → when-not → side effects → limits), which is good, but the payload is longer than it needs to be.

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 no explanation; with that removed, everything an agent needs is present: determinism guarantee, absence of side effects, sibling exclusion, and hard input/latency/size limits that affect how to call it safely.

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 baseline is 3. The description nevertheless adds conceptual meaning the schema lacks: it frames the output as token-bucket behaviour, which is what makes 'burst' and 'tokens_available' interpretable, and ties 'calls' to the total-duration result. It does not give explicit defaults, but the schema already does.

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?

Uses a specific verb plus enumerable outputs (espaciado mínimo, duración total mínima, espera token-bucket) for a clearly bounded resource: a rate limit of N requests per window. It also names the sibling it is not (backoff-schedule), so an agent can separate it from the retry-delay tool without opening either schema.

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?

Explicitly states the trigger condition ("Cuando: un flujo de agente necesita un resultado exacto y repetible para un paso auxiliar") and an exclusion with a named alternative ("No para: calcular los tiempos de espera entre reintentos (backoff-schedule)"). When, when-not and alternative are all present.

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