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

Annotations already declare readOnlyHint, openWorldHint=false, idempotentHint and destructiveHint=false, so the description is not obligated to restate safety. It goes beyond them by stating deterministic output and concrete operational limits (64 KB JSON input, 1 s per call, 1 MB result), which are genuinely useful constraints an agent cannot get from the annotations. It stops short of describing error behavior for malformed or ambiguous dates.

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 labelled structure (Cuándo / No para / Efectos secundarios / Determinista / Límites) is front-loaded and easy to scan. But the whole block is then repeated in an EN version, and the "Cuándo" sentence sprawls across URLs, tokens, versions, IP ranges, HTML, Markdown and agent files — content that does not earn its place for a two-format date converter.

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 explained, and the description still supplies determinism, size/time limits and a routing exclusion — enough for an agent to call it correctly. Remaining gaps are minor: no statement of timezone assumptions or how invalid/non-parseable input is reported.

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?

With one parameter at 100% schema description coverage, the schema already documents the accepted types, the 100-char maxLength and provides an example. The description adds the IMF-fixdate format illustration, but that example is duplicated verbatim in the schema, so the net added meaning is minimal. Baseline 3 applies.

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 first clause names a specific verb and resource pair with both formats spelled out ("Convierte entre fecha HTTP (IMF-fixdate) e ISO 8601 / Unix") and gives a concrete IMF-fixdate example, so an agent immediately knows what it does. It only distinguishes one sibling (http-headers-parse), leaving near-neighbours like retry-after-parse, timestamp-convert and datetime-parse unaddressed. The "Cuándo" list of URLs, tokens, versions and IP ranges slightly blurs the actual scope of the tool.

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?

There is an explicit exclusion with a named alternative: "No para: convertir un bloque de encabezados HTTP crudos... (http-headers-parse)", which is exactly the kind of routing signal an agent needs. The positive "Cuándo" clause, however, is generic boilerplate ("leer, construir o revisar con exactitud") that would apply to dozens of sibling tools and does not tell you when to pick this over retry-after-parse or timestamp-convert.

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