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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, and the description largely restates those ("solo lectura, sin red, sin estado guardado", "Determinista"). The added value is the operational limits block — 64 KB JSON input, 1 s per call, 1 MB result — which is genuine behavioral context an agent cannot get from structured fields.

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 paragraph is front-loaded and segmented with explicit labels (Cuándo / No para / Efectos secundarios / Determinista / Límites), so any line can be scanned in isolation. The cost is full duplication across Spanish and English, roughly doubling tokens for identical information.

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 prose, and annotations plus the limits block cover the safety and determinism story well. Two gaps remain: the default-on deduplication via unique is never mentioned, and the stated "64 KB JSON input" limit sits oddly against the schema's 1,048,576-character text field, leaving ambiguous which bound actually applies.

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 coverage is 100%, so both text and unique are documented with types, defaults and an example, which sets the baseline at 3. However the description is silent on the most consequential parameter behavior: unique defaults to true, so results are deduplicated unless the caller opts out — a caller reading only the prose would not know that.

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 ("Extrae emojis / Finds emoji grapheme clusters") and scopes it precisely by naming what counts as an emoji unit: skin tones, ZWJ sequences, flags. That scope detail is what separates it from generic extractors like extract-numbers or extract-urls in the sibling list, and an agent can pick it without opening the 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 names the boundary case and the alternative tool: "No para: contar la frecuencia de cada carácter (char-frequency)", which is a real routing decision. The positive "When" clause ("transformar, comparar o medir un texto con exactitud") is abstract and doesn't give a concrete trigger, so it stops short of full when/when-not coverage.

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