descargar

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

With no annotations, the description carries the full burden and does it well: it discloses the 25 MB cap, retry/gzip/encoding handling, WAF-block reporting, that alerts from the host's ficha are appended, and that a substitute is offered for dead URLs — all behavior an agent could not infer. Gaps remain on authentication requirements and whether repeated calls are cached or counted against any quota.

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 core action is front-loaded in the opening clause and the second sentence adds the use case without restating anything. The first sentence is very densely packed with clauses, which slightly slows parsing but each clause contributes distinct information.

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?

Behavior is rich enough to call the tool safely, but with no output schema and 0% schema description coverage, the description should explain what the returned summary looks like and what desde/max_caracteres control. As written, an agent can invoke it but not tune it.

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 0%, so the description must explain all three parameters. It only implicitly suggests truncation via "la resume", and the parameters desde and max_caracteres (offset and truncation length) are never mentioned or explained, leaving their semantics and units entirely undocumented.

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 ("Descarga una URL pública") and immediately qualifies it with the machinery it handles: FNMT certificates, User-Agent, retries, gzip, encoding, and a summary in CSV/JSON/xlsx/ZIP. This is clearly distinct from siblings like buscar, ficha, ckan_buscar, which search or look up metadata rather than fetch a raw URL.

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?

"Para cuando tu fetch falle con un .gob.es o para ver qué devuelve una URL" gives a concrete triggering condition, which is exactly the kind of routing signal an agent needs. It stops short of naming siblings to prefer instead or stating when-not to use it (e.g., for JSON APIs already covered by ckan_filas or socrata_filas).

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