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

With no annotations, the description carries the full burden, but it only states the resource and the optional filter. It does not disclose whether login is required, how many activities are returned, ordering, or any side effects, though it is likely a read operation.

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?

One short sentence that is easy to parse and front-loads both the resource and the key filter. It is concise to a fault, sacrificing useful detail, but as a single-purpose line it is efficient.

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?

Given the absence of annotations and the presence of several sibling tools, the description does not supply enough context for reliable selection and invocation. It lacks usage guidance, any mention of prerequisites like login, and behavioral detail that the output schema would not cover.

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?

The schema provides no descriptions (0% coverage), and the description only names 'curso' and 'seccion' in natural language. It confirms seccion is optional but does not explain expected formats, identifiers, or how the filter behaves.

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 description identifies the resource ('activities of a course') and the optional section filter, which is enough to distinguish it from sibling tools like eva_material or eva_calendario. It lacks an explicit verb such as 'list' or 'get', so the action is implied rather than stated.

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 description implies the tool is for retrieving activities tied to a course and optionally a section, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. There is no mention of when to prefer eva_avisos or eva_material.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It says the result is the full text of a notice, but does not mention read-only behavior, authentication requirements, possible errors, or any side effects.

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 description is a single, compact phrase with no redundant wording. It front-loads the core purpose and keeps the parameter clarification parenthetical, which is appropriately sized for a simple tool.

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?

The tool is simple with one required parameter and an output schema, so the description does not need to explain return shape. However, it lacks usage guidance and any behavioral context such as authentication or read-only status, leaving some gaps for an agent deciding to invoke 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 coverage is 0%, so the description must compensate. The phrase 'id de la discusión' adds meaning by clarifying that discusion_id identifies the notice/discussion to fetch, which is helpful, but it does not explain the id's format or provenance.

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 description states the tool provides the full text of a notice via its discussion id, which clearly identifies the resource and action. It distinguishes from the sibling eva_avisos by emphasizing 'full text' of a single notice, though it does not explicitly name the alternative.

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 no explicit guidance on when to use this tool versus alternatives such as eva_avisos. The intended use is only implied by the description and the parameter name, leaving the agent to infer the selection logic.

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

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

With no annotations, the description carries the behavioral burden and does disclose the source ('foro') and that only the latest notices are returned. It does not mention authentication, ordering, or side effects, but for a simple read/list operation with an output schema present, this is adequate though not rich.

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 description is a single short sentence with no filler. The most important scoping information is front-loaded, making it easy to parse quickly.

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?

Given the sibling list and absence of annotations, the description does not clarify how eva_avisos differs from eva_aviso, offers no usage guidance, and leaves 'limite' undefined. The output schema covers return shape, but the missing contextual and parameter information makes the definition incomplete.

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?

The parenthetical 'nombre, código o id' adds useful meaning to the 'curso' parameter beyond the bare string schema. However, 'limite' is not described at all, so with 0% schema description coverage the description only partially compensates for the missing parameter documentation.

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 description identifies the resource ('avisos del foro') and the scope ('un curso'), and clarifies that the course can be specified by name, code, or id. It lacks an explicit verb like 'obtiene' or 'lista', but the plural 'avisos' makes the retrieval intent clear and distinguishes it at least implicitly from the singular sibling eva_aviso.

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?

No guidance is given about when to use this tool instead of eva_aviso or the other course-related tools. There are no conditions, exclusions, or alternatives mentioned.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure, but it only states the default month. It does not clarify whether the operation is read-only, how events are returned, whether there are pagination or date-range limits, or any other behavioral traits.

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 description is a single short, front-loaded sentence with no wasted words. It identifies the resource and the key default behavior efficiently, though it sacrifices helpful detail for brevity.

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?

The tool is simple with two optional parameters and has an output schema, so the description does not need to explain return values. However, it still omits usage routing and behavioral context, making it minimally viable rather than complete.

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?

The input schema has 0% property description coverage, so the text must explain the parameters, but it only mentions the default current month. It does not clarify how mes and anio combine or what valid integer ranges are expected, leaving the agent to infer parameter meaning from the names alone.

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 description clearly identifies the resource as calendar events and includes the default time scope, so an agent can tell this tool is for calendar data rather than announcements or activities. It lacks an explicit verb and does not explicitly distinguish itself from siblings, but the meaning is unambiguous.

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 description gives no guidance about when to choose this tool over siblings such as eva_actividades or eva_avisos. The only usage hint is the default current month, but there is no explanation of when to call this tool or what alternative fits different needs.

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

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

The verb 'Lista' implies a non-mutating read operation, but no annotations are provided and the description does not mention prerequisites such as EVA login, pagination, or error behavior. This is adequate for a simple list tool but does not fully carry the behavioral burden.

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 description is a single, front-loaded sentence with no filler. It states the action, the resource, and the expected fields in a compact and readable way.

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?

Given that the tool takes no inputs and an output schema exists, the description is nearly complete for invoking it correctly. The only minor gaps are lack of explicit authentication context and no guidance about when a sibling tool would be preferred, but neither prevents correct use.

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?

The tool has zero parameters, so the schema conveys all parameter information; the baseline is 4. The description adds value by revealing the output fields (id, nombre, código), which sets expectations for the returned data.

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 description uses the specific verb 'Lista' and names the exact resource, 'los cursos matriculados en el EVA', followed by the returned fields (id, nombre, código). This clearly distinguishes it from sibling tools such as eva_material or eva_calendario, which target different resources.

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 description makes the context clear: use this tool to list the courses the user is enrolled in. It does not explicitly name alternatives or exclusion criteria across the siblings, but for a zero-parameter list tool the intended use is readily inferable and unambiguous.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does disclose path normalization behavior, which is useful, but it omits filesystem side effects such as directory creation or overwrite behavior, authentication requirements, and failure behavior.

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 description is compact and well-structured: the action and return behavior are front-loaded, followed by the path-format caveat. Every sentence carries necessary information without redundancy.

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?

The output schema likely covers return structure, but a required parameter (`curso`) remains undefined in both schema and description. The description also does not mention authentication or prerequisites, despite the existence of an eva_login sibling, so an agent cannot reliably know how to construct a valid call.

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?

The description adds meaningful semantic value for `destino` by specifying accepted path formats and automatic normalization, which the schema lacks entirely. However, `curso` is left completely undocumented, and with 0% schema description coverage, the description only partially compensates for the overall gap.

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 description states a specific action ('Descarga los materiales de un curso'), the target resource, the destination, and the return value ('devuelve las rutas'). This clearly distinguishes it from sibling tools like eva_material, which likely deals with material metadata rather than downloading.

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 no explicit guidance on when to use this tool versus alternatives like eva_material or eva_login. The intended use case is only implicitly inferable from the verb 'Descarga', and no prerequisites, exclusions, or alternative tool pointers are provided.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly discloses the main side effect—discarding the cached session—and that the login is forced. However, it does not mention whether credentials are required, whether this invalidates other active state, or what failure or error behavior might look like.

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 description is a single, efficient sentence with no filler. The core action and side effect are front-loaded, and every word adds value.

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?

For a zero-parameter tool with an output schema and no nested inputs, the description is largely complete: it identifies the action and primary side effect. It could add context about when to choose this tool, such as stale session detection, but nothing essential for invoking it correctly is missing.

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?

The tool has zero parameters, so there is no parameter meaning for the description to add. With schema coverage at 100% and an empty schema, the baseline of 4 for parameterless tools is appropriate, and the description correctly adds no parameter-specific detail.

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 description clearly states the tool's action: force a fresh login and discard the cached session. It is specific about the resource ('login') and the behavior, distinguishing it from the sibling data-retrieval tools rather than merely repeating the title.

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 description implies this should be used when a fresh login or session reset is needed, but it does not explicitly state when to use it versus alternatives or whether it should precede other eva_* calls. There is no exclusion or alternative routing, only an implied usage context.

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

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

Sin anotaciones, la descripción aporta un rasgo conductual: no descarga el material. Sin embargo, no informa si requiere autenticación previa, qué devuelve exactamente ni si la operación es de solo lectura, por lo que la carga informativa queda cubierta solo parcialmente.

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?

La descripción es una frase breve y sin redundancias, con la distinción clave ('sin descargar') claramente integrada. No hay palabras de relleno y la información esencial está presente.

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?

Es una herramienta simple con un solo parámetro y esquema de salida disponible, por lo que la descripción es suficiente para una invocación básica. Faltan detalles sobre el formato esperado del parámetro y los prerrequisitos de autenticación, lo que impide una completitud total.

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?

El esquema define un único parámetro 'curso' con 0% de cobertura en la descripción. El texto asocia ese parámetro al curso cuyos materiales se obtienen, lo cual añade algo de significado, pero no especifica si se trata de un ID, nombre o slug.

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?

La descripción identifica claramente el recurso: materiales de un curso, compuestos por archivos y páginas. El matiz 'sin descargar' lo distingue de la herramienta hermana eva_descargar_material, aunque carece de un verbo explícito como 'listar' u 'obtener'.

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?

El texto deja implícito que esta herramienta se usa para consultar materiales sin descargarlos, diferenciándose del flujo de descarga. No menciona explícitamente a eva_descargar_material ni define cuándo no usarla, pero el contexto es suficientemente claro.

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