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

Annotations already declare readOnlyHint, openWorldHint=false and idempotentHint, so 'sin efectos secundarios' and 'determinista' are largely restatements. What genuinely adds value beyond annotations is the operational envelope (1 s per call, up to 1 MB of result) and the note that results include language tags and line counts. One caveat: the stated 'input up to 64 KB' conflicts with the schema's text maxLength of 1048576, which could mislead an agent sizing its input.

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 content is front-loaded and cleanly segmented (purpose / when / not-for / effects / limits), but the full text is duplicated in Spanish and English and then terminated with a pointer '[EN completo / full EN: inputSchema.description]' that repeats what is already in the schema description. Roughly half the length is redundancy, which dilutes the signal for a tool this simple.

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 an output schema present, the description correctly avoids explaining return values, and it covers side effects, determinism, time and size limits, and the sibling boundary. The only real gap is the internal inconsistency between the 64 KB input cap and the schema's 1 MB text maxLength, which leaves the actual input limit 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?

Schema description coverage is 100%, so both `text` and `language` are documented with types, maxLength and an example, giving a baseline of 3. The description only adds that filtering by language tag is optional and how output is tagged; it offers no extra syntax or matching rules (e.g. case sensitivity, alias handling like 'js' vs 'javascript') that the schema does not already convey.

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 ('Extracts fenced code blocks (``` or ~~~) from Markdown or LLM output'), including the delimiters, the language tags and the line counts, and even names the sibling it is not (json-extract). An agent can distinguish it from json-extract, markdown-* and html-* extractors without opening any 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?

Has explicit 'Cuando/When' (exact, repeatable bookkeeping step: tokens, costs, retries, chunking, ranking, JSON clean-up) and explicit 'No para/Not for' with the named alternative json-extract plus the condition that selects it (parsing JSON objects/arrays embedded in free text). Nothing is left to inference.

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