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

Annotations already declare read-only, idempotent and closed-world, but the description adds concrete operational limits absent from the structured data: 64 KB JSON input, 1 s per call, 1 MB result, plus an explicit determinism guarantee. No contradiction with annotations, though 'sin red / sin estado' partly restates readOnlyHint and openWorldHint.

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 text is duplicated wholesale in Spanish and English, and the English copy is truncated into a self-reference ('[EN completo / full EN: inputSchema.description]'). Half of each version is an irrelevant task enumeration (headers, tokens, IP ranges, HTML documents) that does not pertain to URL construction, so much of the length does not earn its place.

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?

All four parameters are covered by schema, an output schema exists so return values need no explanation, and the description supplies limits, determinism and one exclusion. The only substantive gap is sibling routing against url-resolve and query-build, which are the nearest alternatives.

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 100% schema coverage the baseline is 3, and the description earns extra by explaining encoding semantics the schema does not: each path segment is percent-encoded, and array-valued query parameters repeat the key. That is real behavioral meaning beyond the property descriptions.

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 opening sentence gives a specific verb and resource with its inputs ('Construye una URL desde una base, segmentos de ruta y parámetros de consulta'), which clearly separates it from url-parse. However, the 'Cuándo' clause then claims relevance to HTTP headers, tokens, IP ranges, HTML/Markdown documents and agent-readiness files — none of which a URL builder handles — muddying what the tool actually does.

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 ('No para: analizar una URL absoluta (url-parse)'), which is good routing. But the closest siblings, url-resolve (relative resolution) and query-build (query-string construction), are never named, and the positive 'when' guidance is largely irrelevant boilerplate rather than a condition that selects this tool.

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