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

Annotations already declare readOnly, non-open-world, idempotent and non-destructive, so the description's 'sin red, sin estado guardado' is largely restatement. It earns credit for going beyond them: 'heurísticamente' plus 'Puede ser falsificado' warns the result is best-effort and spoofable, and the concrete limits (64 KB input, 1 s per call, 1 MB result) are operationally useful facts an agent cannot get from 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?

Core purpose is front-loaded, which is good, but the text is duplicated wholesale in Spanish and English and padded with a boilerplate sentence listing unrelated artefact types (tokens, IP ranges, HTML files) that do not describe this tool. Roughly half the content is redundancy or noise rather than scope.

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?

With only one required parameter and an output schema present, the description need not explain return values, and it does supply the missing operational context: determinism, spoofing caveat, time/size limits and an explicit sibling exclusion. It falls short only because the misleading 'Cuándo' list and the bilingual duplication add ambiguity rather than completeness.

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?

The single parameter is fully covered by the schema (type, required, maxLength 2048, an example UA, and its own description), so the schema does the heavy lifting. The description adds no per-parameter detail such as accepted input forms or the interaction between the 2048-char field cap and the 64 KB payload cap.

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 ('Analiza heurísticamente un User-Agent') and enumerates the exact extracted fields: browser+version, engine, OS, device class and known bots. That is enough for an agent to tell it apart from neighbours like accept-language-parse or http-headers-parse without opening a 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?

Provides an explicit negative routing rule: 'No para: analizar una cabecera Accept-Language ... (accept-language-parse)', which names the closest sibling and the condition that selects it. The positive 'Cuándo' clause, however, is generic boilerplate ('una URL, una cabecera HTTP, un token, ... un documento HTML o Markdown') that could wrongly suggest the tool parses URLs or documents, so the guidance is clear on exclusion but noisy on inclusion.

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