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

Annotations already cover readOnly/openWorld/idempotent/destructive, yet the description still earns credit by adding operational limits absent from the annotations: 64 KB JSON input, 1 s per call, 1 MB result, and the scope caveat "Not a full parser". The side-effects and determinism sentences largely restate the annotations, but the limits and the partial-parser caveat are genuine added context.

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 check list is dense and front-loaded, and the ES/EN split is sensible. But the "Cuándo" clause is wasted — worse, wrong — length, and the EN block near-verbatim duplicates the inputSchema description, so part of the text does not earn its place at the call site.

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?

Annotations plus an output schema mean safety and return shape need no prose coverage, and the check list makes the contract clear. The definition is still missing an accurate statement of when to reach for it (the 'when' sentence points at URLs/HTTP headers instead), and the 64 KB vs 256 KB mismatch leaves the input-size boundary ambiguous.

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?

There is a single required parameter with 100% schema description coverage and a worked example, so the schema already does the work and baseline 3 applies. The description adds what is inspected in the text but nothing about the parameter itself, and the stated "64 KB" input cap conflicts with the schema's `maxLength: 262144` (256 KB), which could mislead on truncation behavior.

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+resource ("Revisa ... un texto DOT de Graphviz sin renderizarlo") and enumerates exactly what it checks: header form, balanced braces/brackets/quotes, `->` only in digraphs, `--` only in graphs, key=value attributes, plus node/edge counts. It explicitly names the sibling it is not ("No para: ... Mermaid ... (mermaid-check)"), so an agent can separate dot-check from mermaid-check 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?

The exclusion clause is precise and routes to the right sibling (mermaid-check). However the "Cuándo" sentence is off-topic boilerplate carried over from another tool ("una URL, una cabecera HTTP, un token, ... un documento HTML o Markdown") and does not describe a DOT-checking scenario at all, which actively misleads selection. Correct exclusion plus an actively wrong 'when' clause leaves the agent to infer the real usage from the purpose sentence alone.

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