Descargar Materiales de EVA a una Carpeta

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

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=true; the description usefully reconciles this by clarifying that the write is local only ('No modifica nada en EVA') and that re-downloads can be forced via cache ('forzar_refresco'). It still omits whether an EVA session must already be active and how errors are surfaced.

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?

Four short sentences, front-loaded with what the tool does and an example, then the key parameters and the default destination. Dense with relevant information and no filler, though the parameter sentence duplicates schema content.

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?

Covers defaults (Descargas/UCA), filtering strategy and the no-remote-modification guarantee, which is substantial for a 6-parameter tool. With no output schema, however, it never says what is returned (file list, count, failures), nor whether uca_iniciar_sesion must precede it — a notable gap given authentication siblings exist.

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%, and the description only restates what the schema already documents (curso_id source, query filtering, default carpeta_destino). No extra syntax, interaction rules (e.g. query optional when curso_id is given) or format detail is added beyond the schema text.

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 archivos de EVA ... a una carpeta de tu computadora') and clarifies the scope includes files nested inside folders, which no sibling would do. The example ('todos los parciales de una materia') makes the operation immediately recognizable and distinguishes it from eva_buscar_materiales (search) and eva_leer_archivo (read).

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?

Gives concrete usage guidance: use 'curso_id' obtained from eva_materias plus 'query' to filter, with a worked example. It does not explicitly say when to prefer this over eva_buscar_materiales or eva_leer_archivo (e.g. bulk download vs. single-file inspection), leaving that inference to the agent.

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