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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds scope context — that it returns balance, eligibility to sit exams, and in-progress paperwork — but says nothing about session/auth prerequisites (there is a uca_iniciar_sesion sibling) or about freshness of the data, which matters for a "al día/pendientes" query.

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?

Two tight sentences that front-load the resource and then list returned data. Minor waste: the "[EXPERIMENTAL]" marker is duplicated verbatim from the title, costing space without new 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?

For a one-optional-param, read-only tool with no output schema, the description covers what the agent needs to decide to call it and what categories of data come back. It stops short of indicating result shape or whether a session must already exist, which is the only meaningful gap.

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?

There is a single optional enum parameter with 100% schema description coverage, so the schema already explains 'todo'/'aranceles'/'tramites' and the default. The description never references the filter, adding no meaning beyond the enum. Baseline 3 applies.

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 ("Consulta") and two concrete resources (aranceles, trámites administrativos), then enumerates the data returned: saldo, habilitación para cursar/rendir, trámites en curso. That is enough to tell it apart from the eva_* and guarani_* siblings, but it never names an overlapping sibling (e.g. guarani_estado_cursada) to disambiguate the academic-status overlap.

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 domain (Campus Autogestión fees and administrative paperwork) implies when to reach for it, but there is no explicit when-to-use, when-not-to-use, or named alternative among the 20 sibling tools. An agent must infer that this is the place for payment status versus guarani_mis_inscripciones_examen for exam registration.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the purpose statement — nothing about result ordering, whether the search spans all enrolled courses or only the one in curso_id, truncation at 'limite', or pagination. With annotations carrying the safety burden, the low score reflects the absence of any added operational detail.

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?

A single, front-loaded sentence with no filler and no repetition of schema details. It is efficient, though its brevity borders on under-specification for a tool with several siblings.

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?

Annotations cover the safety profile and the schema fully documents all parameters, and the description does enumerate the result types (recursos, consignas, documentos). Still, for a search tool among many EVA siblings, what is missing is routing guidance and any notion of result scope, which the description never addresses.

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 all three parameters (query, limite, curso_id) are documented with types, bounds and a default, so the schema does the heavy lifting. The description only echoes the keyword aspect via 'por palabra clave' and says nothing extra about how limite or curso_id change result behavior.

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 ('Busca') with concrete resources ('recursos, consignas y documentos') and the mechanism ('por palabra clave'), so the agent understands exactly what the tool retrieves. It does not, however, distinguish itself from sibling content tools like eva_contenido_curso, eva_descargar_materiales or eva_leer_archivo, leaving overlap for the agent to resolve.

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?

'por palabra clave' implies the tool should be used when a search term is available, but nothing states when to prefer it over browsing via eva_contenido_curso or fetching a specific item with eva_descargar_materiales/eva_leer_archivo. The optional curso_id parameter hints at scoped search but no guidance is given on when to scope.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile needs no restating. The description adds a useful signal that the payload is large enough to warrant context budgeting, but says nothing about caching behavior beyond what the forzar_refresco schema field already documents, nor about response shape or depth.

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?

Two tight sentences: the first front-loads what is returned, the second the filtering capability and its purpose. No filler, no repetition of the title.

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 a fully documented 4-parameter schema, rich annotations, and no output schema, the description covers what an agent needs to call it correctly. A brief note on whether results are hierarchical (sections containing modules) would close the remaining gap.

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 every parameter including the cache-invalidation flag is already documented. The description only echoes the tipo/sección filtering idea, which is the baseline expectation at full coverage.

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 ("Lista") and enumerates the resources returned (secciones, módulos, tareas y recursos) scoped to a single course, which cleanly separates it from eva_materias (course-level listing) and eva_tareas_y_notas. It does not explicitly name a sibling it replaces, so it lands at 4 rather than 5.

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?

"Permite filtrar por tipo o sección para presupuestar contexto" implies the usage pattern (narrow the call to reduce context cost) but never states when to prefer this over eva_buscar_materiales or eva_tareas_y_notas, nor any exclusions.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: ambiguous-match handling that returns candidates, the fechasDetectadas and avisoFechas fields, and explicit reporting when no document exists.

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 the core action and followed by edge-case behavior. Each sentence carries information; only the closing clause slightly restates the cronograma/programa pairing already established earlier.

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 no output schema, the description compensates by naming the key return fields and the failure/ambiguity paths, which is what an agent needs to interpret results. The one gap is that it does not clarify its boundary against guarani_cronograma_evaluaciones or other EVA file tools.

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 single materia parameter is fully documented with type, length bounds and examples. The description only implies that the materia argument drives the search, adding no format or disambiguation detail beyond the schema, so baseline 3 applies.

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: locate the cronograma/programa file for a subject in EVA and extract exam/retake/delivery dates. That is far more than a restatement of the name. However, it never distinguishes itself from related siblings such as eva_buscar_materiales, eva_contenido_curso or especially guarani_cronograma_evaluaciones, which an agent could easily confuse it with.

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 explains internal fallback behavior (pick by name, else return candidates) and the no-file case, which implies usage. But it gives no explicit when-to-use/when-not guidance and names no alternative tool, so the agent must infer that this is for EVA-hosted documents rather than Guaraní evaluation data.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered and '(Lectura pura)' merely restates it. The description does add value by enumerating what the response contains (apertura/cierre dates, attempts, grades), which matters since there is no output schema, but it says nothing about the 45–60s cache, auth needs, or pagination.

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?

A single front-loaded sentence with the resource first and the read-only qualifier last; no filler. It is dense and efficient, though the parenthetical is the weakest part since it duplicates annotation data.

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 two-optional-parameter read tool with full schema coverage and no output schema, the description adequately conveys purpose and return contents. It falls short on routing: with both EVA and Guaraní evaluation tools in the sibling set, an agent gets no signal about which to choose.

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 both parameters are well documented there, including the meaningful omission behavior for curso_id and the cache bypass for forzar_refresco. The description adds no parameter detail of its own, so the baseline 3 applies.

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 concrete verb ('Consulta') and specific resources (cuestionarios, exámenes parciales) plus the data returned (fechas de apertura/cierre, intentos, calificaciones), scoped to EVA. It doesn't name a sibling to distinguish from — notably guarani_cronograma_evaluaciones, which covers exam dates from a different system — so the EVA/Guaraní boundary is only implied.

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 when-to-use or when-not-to-use guidance, no prerequisites, and no named alternative. '(Lectura pura)' signals a read-only operation but not a selection criterion. The key usage fact — that omitting curso_id sweeps the calendar and current subjects — lives only in the schema, not in the description.

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?

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.

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

Las anotaciones ya declaran readOnlyHint, idempotentHint, openWorldHint y destructiveHint=false, por lo que la carga de divulgar el perfil de seguridad es menor. La descripción aporta que la consulta combina dos conjuntos (vencimientos y avisos de cátedra) y el horizonte por defecto de 7 días, pero no aclara el formato de retorno, el comportamiento del límite máximo de 30 días ni si curso_id filtra ambos conjuntos.

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?

Una sola oración densa pero sin relleno, con el núcleo (vencimientos próximos) al frente y el default temporal entre paréntesis. Podría dividirse para resaltar la parte de avisos, pero cada elemento informa.

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?

Para una herramienta de solo lectura con 2 parámetros opcionales, cobertura de esquema total y sin output schema, la descripción cubre propósito, alcance temporal y la doble naturaleza del resultado. Falta solo precisar cómo se comportan los avisos y el filtrado por curso, detalles menores.

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?

La cobertura de descripción del esquema es 100%: ambos parámetros (dias y curso_id) ya están documentados en el schema con sus rangos y valores por defecto. La descripción solo refuerza el default de 7 días, sin añadir sintaxis ni semántica adicional sobre curso_id, por lo que aplica la línea base de 3.

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 concrete verb ("Consulta") and a specific resource: tareas/trabajos prácticos/actividades con vencimiento próximo, más avisos recientes de cátedra. El alcance temporal (próximos días, por defecto 7) acota bien, pero no nombra a los hermanos cercanos (eva_tareas_y_notas, eva_cronograma) para diferenciarse explícitamente.

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 uso queda implícito en "en los próximos días (por defecto 7 días / la semana que viene)", lo que da contexto temporal suficiente para invocarlo. Sin embargo, no indica cuándo NO usarlo ni remite a alternativas como eva_tareas_y_notas para el listado completo de tareas o eva_cronograma para el calendario.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is fully covered and the description need not restate it. Beyond that it adds only one behavioral trait, that messages are tagged with a security notice, without explaining what that tagging means or how it surfaces. Caching behavior (45-60 s) is disclosed in the schema for forzar_refresco rather than in the description.

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?

A single front-loaded sentence with the verb first and no filler. It is appropriately sized for a simple list tool, though the cryptic trailing parenthetical costs some clarity.

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 no output schema, the description carries the burden of describing returns, and it only names the content types without indicating ordering, result shape, or how many messages come back by default. Safety and side-effect behavior are adequately covered by annotations, so the gap is limited to return-value detail.

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 all three parameters (limit, curso_id, forzar_refresco) carry their own descriptions including defaults and the cache window. The prose adds no parameter-level information such as filtering semantics for curso_id or ordering relative to limit, so the baseline 3 applies.

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 concrete verb ("Obtiene") and concrete resources (avisos institucionales, mensajes de foros de cátedra) with a recency qualifier ("últimos"). The agent can distinguish it from eva_responder_foro by the read-only listing intent, though the boundary with eva_hilo_foro (reading a specific thread) is not spelled out. The parenthetical "etiquetados con aviso de seguridad" is somewhat opaque and slightly muddies the resource definition.

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 when-to-use, when-not, or alternative routing. The agent must infer that this is the right tool when the user asks about recent announcements, and nothing tells it to prefer eva_hilo_foro for a single thread or eva_contenido_curso for course material. Usage is only implied by the phrase "últimos avisos".

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?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false; the description adds real value by clarifying that the write stays in an editable draft state and that user confirmation is required. It never says whether an existing draft is overwritten or what happens on success, which is exactly the context the destructive/non-idempotent hints make relevant.

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?

Two short sentences, front-loaded with the action and scope, nothing padded. The duplicated [EXPERIMENTAL] marker from the title is the only redundant token.

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 mutation tool with no output schema and destructive/non-idempotent hints, an agent cannot tell from the description what the call returns (draft ID? URL?), whether it overwrites a prior draft, or how to choose between file and inline text. Annotations cover the safety profile but the outcome semantics remain unaddressed.

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 100%, so all three parameters are documented in the schema with types and limits. The description only echoes "archivo o texto" and omits the important unwritten rule that ruta_archivo and texto_en_linea are alternative content sources (mutually exclusive, only cmid required), so it adds little beyond the schema.

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 (subir/guardar) and resource (borrador de tarea en EVA) plus the two content channels (archivo o texto). It does not name a sibling to differentiate from (e.g. eva_responder_foro or a final submission tool), so it stops short of 5.

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?

"en modo borrador editable" implies the use case (save without submitting) and "Requiere confirmación del usuario" gives a precondition, but there is no explicit when-not or alternative named. The agent must infer the draft-vs-submit boundary.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that results are ordered and include all replies, but says nothing about size, pagination, truncation or access requirements for large threads.

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 compact sentence with the operation and scope front-loaded and no filler. It could have used the remaining space for the pagination/alternatives gap, but nothing present is wasted.

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 read-only retrieval tool with no output schema, the description adequately says what comes back at a high level (all posts, ordered). It omits how large threads are handled and what fields each message contains, which an agent would need to plan a response.

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 single required parameter discusion_id is fully documented in the schema. The description adds no format, validation or sourcing detail beyond it, so the baseline 3 applies.

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 ('Obtiene') and resource ('el debate o hilo completo de un foro de cátedra en EVA') plus the scope of the return (all replies and messages, ordered). It implicitly differentiates from siblings like eva_foros (listing) and eva_responder_foro (posting), but never names them explicitly.

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?

Usage is only implied by the word 'completo' — an agent can infer this is for reading an entire thread rather than listing forums. There is no explicit when-to-use, when-not, or reference to an alternative sibling tool.

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?

Adds real context beyond the annotations: HTTPS allowlist enforcement, extraction behavior differing by file type (text vs image blocks for scans), and a side-effect warning that querying resources/folders registers a visualization in the platform. That last detail is behavioral information annotations cannot express. It stops short of covering caching (forzar_refresco) implications.

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?

Two dense sentences, front-loaded with the primary action and result format. The trailing side-effect note earns its place, though its reference to 'consulta de recursos o carpetas' is slightly ambiguous about which operation is actually being persisted.

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 5 optional parameters and no output schema, the description correctly spends its words explaining the return shape (text vs image blocks) and the access constraint. Missing only the url-vs-cmid decision guidance and cache behavior, which are moderate gaps rather than blocking ones.

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 100%, so both the url constraint (must belong to eva.uca.edu.ar) and the cmid alternative are already documented in the schema. The description repeats the security constraint but adds nothing about choosing url vs cmid, pagination defaults, or cache override semantics.

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 chain (download safely, extract text, return image blocks) and names the exact resource types (PDF, Office, scanned). An agent knows what it gets back. It does not distinguish itself from the overlapping sibling eva_descargar_materiales, which keeps it from a 5.

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 purpose implies usage (fetch content from a specific file URL or cmid), but there is no explicit when-to-use/when-not guidance and no routing to eva_descargar_materiales or eva_buscar_materiales, even though those siblings overlap. Usage must be inferred.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile needs no restating. The description adds meaningful scope behavior (active by default, archived hidden unless flagged), but omits that a prior uca_iniciar_sesion is required and says nothing about in-memory caching or result size.

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?

Two sentences, zero filler, with the default listing behavior front-loaded ahead of the archive toggle.

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-required-parameter read tool with full schema coverage and complete annotations, this is close to sufficient; it even notes that course identifiers come back. Only the shape of the returned course entries and the login precondition are left unstated, and there is no output schema to cover them.

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 100%, with both booleans self-documented, so the baseline is 3. The description restates incluir_archivadas (adding only the 'past or hidden' nuance) and says nothing about forzar_refresco, leaving that entirely to the schema.

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: lists virtual classrooms/enrolled subjects in EVA with their course identifiers. That clearly separates it from sibling content tools like eva_contenido_curso or eva_tareas_y_notas, which operate on a single course once its id is known.

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?

Explains the default behavior (active courses) and the exact condition for widening scope with incluir_archivadas: true, which is real usage guidance. It stops short of naming alternatives or stating that this is the entry point before other eva_ tools, so no explicit exclusions.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the write nature is covered. The description adds genuinely new behavioral context beyond that: the full text is shown to the user and an explicit user confirmation is required before publishing — a confirmation gate the agent must respect. It does not warn that repeated invocations create duplicate posts (the non-idempotent consequence).

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?

Two short sentences, zero filler, with the confirmation requirement front-loaded right after the action statement. Nothing redundant with the schema.

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 2-parameter write tool with full schema coverage and safety annotations, the essential shape is there, but the description says nothing about what the tool returns (post ID, URL) or what error conditions look like (closed thread, expired session, over-length message). With no output schema, a brief note on outcomes would have closed the gap.

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 100% and both parameters carry descriptions (message with 1-350 char bounds, numeric thread ID), so the schema does the heavy lifting. The description adds no format, escaping or content constraints beyond it; baseline 3 applies.

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?

Names a specific verb and resource ("Publica una respuesta en un foro de cátedra de EVA"), so an agent knows this writes a reply into a discussion thread. It does not differentiate from the read-side siblings eva_foros / eva_hilo_foro, nor state whether it can create new threads as well as replies.

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?

Usage is only implied: the `discusion_id` parameter and the word "respuesta" suggest you reply to an existing thread. Nothing tells the agent when to prefer this over reading with eva_hilo_foro, nor any prerequisites (enrollment, enrollment role, course 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered without the description. The text adds only the set of fields returned; it says nothing about scoping semantics, how overdue vs. upcoming items are treated, or result volume/pagination. No contradiction with annotations.

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 front-loaded sentence with no filler. Slight redundancy between "plazos de entrega" and "fechas límite", which convey nearly the same thing, keeps it from a 5.

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 no output schema, the description should sketch the return shape (e.g., tasks grouped by course, submission status fields) so the agent can plan around it; that is missing. For a two-parameter read tool with full annotations the remaining gap is modest but real.

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 curso_id (omit for all subjects) and incluir_cerradas (default false) are fully documented in the schema. The description adds no extra meaning to either parameter, so the baseline 3 applies.

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 ("Obtiene") and enumerates the resources it returns: tareas, plazos de entrega, estado de entregas y fechas límite en EVA. Clear enough to know what it does, but it never distinguishes itself from overlapping siblings like eva_entregas_proximas or eva_cronograma.

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 indication of when to pick this tool over eva_entregas_proximas (which also surfaces upcoming deadlines) or eva_cuestionarios (assessment-type tasks). No exclusions, prerequisites, or context of use are given.

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?

Annotations declare it is a non-read-only, non-idempotent, non-destructive, closed-world call; the description usefully adds what annotations cannot: the deliverable is a PDF with an institutional validation code, and the invocation is gated by an explicit user confirmation. It stops short of saying that an emission creates/records a new solicitud in Guaraní and that repeated calls may produce duplicates unless forzar_nueva is set.

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?

A single dense sentence with the verb, resource, output format and the confirmation constraint front-loaded before any detail. No filler, though the parenthetical variant list makes it slightly crowded.

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 6-parameter, fully documented, no-output-schema mutation tool this covers purpose and output format adequately but omits the two things an agent most needs: whether an active Guaraní session is required, and that emission creates a record (and may duplicate) unless forzar_nueva is true — plus no routing to guarani_historial_constancias.

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 all six parameters (copias, carrera, presentar_a, forzar_nueva, observaciones, tipo_constancia) are already documented in the schema. The description only echoes three of the five enum values and says nothing about the other parameters, so it matches the baseline rather than adding meaning.

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 concrete verb pair (emite y descarga) and a concrete resource (Constancia de Alumno Regular, with variants actividades_aprobadas/promedio) produced as PDF from SIU Guaraní. It is clearly distinguishable from read-only siblings like guarani_historial_constancias, though it never names that sibling explicitly.

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 statement of when to use this tool versus the existing guarani_historial_constancias (view issued certificates) or when a new emission is warranted. The phrase 'Protegida por confirmación del usuario' gestures at a workflow but gives no actionable condition, exclusion, or prerequisite (e.g., active session).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait: when a materia is supplied, it performs a two-directional dependency analysis (blocking prerequisites and dependent future subjects). It does not describe the shape of the returned plan data, which is a minor gap given annotations carry the safety 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?

Two sentences, front-loaded with the primary purpose followed by the conditional-mode behavior. No filler, though the first sentence packs four separate outputs into one clause, which slightly dilutes scannability.

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 read-only informational query with only two optional params and full schema coverage, the description is largely sufficient, and annotations cover the safety profile. The one missing piece is any hint of what the returned plan/correlativity data looks like, since there is no output schema, but this is a minor gap for a lookup tool.

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 100%, so both params are already documented as optional strings with name-or-code semantics. The description adds real value beyond the schema by explaining what supplying materia actually does — analyzing which correlativas block it and which future subjects depend on it — which is more than the schema's 'materia a analizar'.

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 (Consulta) and resource (plan de estudios interactivo, materias por año, estado de aprobación, correlatividades), so the agent knows it is a read query over the curriculum. However, 'estado de aprobación' and curriculum planning overlap conceptually with siblings like guarani_progreso_carrera and guarani_plan_optimo, and the description makes no attempt to distinguish itself from them.

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 second sentence implies usage context: 'Si se especifica una materia' triggers a dependency analysis, which tells the agent the optional materia param switches behavior. But there is no explicit when-to-use/when-not guidance and no naming of alternatives (progreso_carrera, plan_optimo, materias_habilitadas), so the agent must infer which tool fits its need.

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?

Annotations already declare readOnly, idempotent, non-destructive, open-world access, so safety is covered. The description adds real behavioral context beyond that: the data source (SIU Guaraní), the default upcoming-only filter, the caveat that coverage is incomplete, and the name of the field that signals missing data. It stops short of describing result shape or ordering, which keeps it from a 5 given there is no output schema.

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?

Three sentences, front-loaded with purpose, then default behavior, then the critical limitation and fallback. No filler, and the 'IMPORTANTE' marker correctly flags the one caveat that could cause a wrong tool choice.

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-required-parameter, read-only query tool with no output schema, the description supplies source, defaults, a coverage caveat and a fallback route. The main remaining gap is what happens when 'carrera' is omitted (all current cursadas?) and whether results are ordered, but nothing critical to a correct invocation 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?

Schema coverage is 100%, so all three parameters are already documented, including their defaults. The description's 'por defecto solo las próximas' restates what incluir_pasadas already says and adds no syntax or edge-case detail; 'carrera' is not discussed at all. Baseline 3 is appropriate when the schema carries the semantics.

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 concrete resource and scope: official partial/final/other exam dates for the student's current courses from SIU Guaraní, including time and comisión. It also implicitly separates itself from the sibling eva_cronograma, which the last sentence names explicitly, so an agent can route between the two academic systems without opening either 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?

Explicitly states the default behavior ('por defecto solo las próximas') and gives a concrete conditional fallback: when a subject appears in materiasSinFechasCargadas, use eva_cronograma, eva_entregas_proximas and eva_cuestionarios instead. That is a named alternative plus the condition that selects it, which is the strongest form of routing guidance.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the useful nuance that the surveys are institutional and mandatory, but says nothing about response shape (e.g., whether it returns a flag, a list of courses, or deadlines).

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?

A single well-formed sentence with the resource and its qualifiers front-loaded and no filler. It is appropriately sized for a one-parameter read-only lookup.

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 simple read-only check with no output schema and one optional parameter, the description conveys enough to invoke it correctly. The remaining gap is what the result contains (boolean vs. list of pending surveys), which an agent would have to discover at runtime.

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?

There is a single optional parameter 'carrera' with 100% schema description coverage ('Nombre o código de la carrera'), so the schema already carries the semantic load. The description never mentions the parameter, its purpose, or what happens when it is omitted (all careers? default?), adding nothing beyond the schema.

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 ('Consulta') and resource ('encuestas docentes institucionales obligatorias o pendientes') scoped to SIU Guaraní, so an agent knows it is a yes/no-style pending-survey check. It does not explicitly distinguish itself from sibling questionnaires like eva_cuestionarios (EVA vs. Guaraní), leaving that separation implicit via the system name.

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?

Usage is implied: call it to check whether the student owes mandatory teaching surveys in Guaraní. There is no explicit statement of when not to use it or which sibling to use instead (e.g., eva_cuestionarios for EVA-side questionnaires), so the agent must infer routing.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral content by disclosing exactly which data is returned (regularidad, inasistencias acumuladas). It does not say whose cursadas are reported (authenticated student only?) or how the optional career filter affects the result set.

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?

A single, front-loaded sentence that lists the returned data points with zero filler. Nothing could be removed without losing 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?

With no output schema, the description is the only source of return-value information, and it does list the reported fields, which is a plus. However, for an openWorld tool with an optional filter parameter, it omits scope (per-student vs. filtered by career) and any note on data freshness or how absences are counted. Adequate but with clear gaps.

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 there is only one optional parameter ('carrera'), so the schema already carries the semantics. The description never references the parameter or explains whether it narrows the output to one career. Baseline 3 is appropriate since the schema does the work.

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 names a specific verb ('Detalla') and a concrete set of resources: active courses, schedules, regularity status and accumulated absences in SIU Guaraní. An agent can tell this is about current enrollment status, not historical records or exam tables. It stops short of naming how it differs from close siblings like guarani_horario_semanal or guarani_historia_academica.

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 guidance on when to invoke this tool versus alternatives such as guarani_horario_semanal (weekly schedule) or guarani_progreso_carrera, despite heavy overlap in the sibling list. Usage is only inferable from the description's field list. No exclusions, no prerequisites, no mention of whether authentication is required.

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?

Annotations already state readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the scope of returned data but says nothing about authentication/session prerequisites, behavior when carrera is omitted, or pagination. For a read-only tool with complete annotations, 3 is appropriate.

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?

A single front-loaded sentence with no filler; the key noun 'Analítico completo' comes first and the list of contents follows immediately.

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 description lists what the tool returns, which is helpful given there is no output schema. However, it omits prerequisites (e.g., SIU Guaraní login/session) and does not clarify what happens without the optional carrera filter, leaving gaps for an agent that must decide whether it can call this tool directly.

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?

There is only one optional parameter (carrera) and schema description coverage is 100%, so the schema already explains its semantics. The description never mentions the parameter or its default behavior, which puts it at the baseline 3 for high-coverage schemas.

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 names a specific resource ('Analítico completo') and enumerates its contents (finales aprobados, materias pendientes, notas, promedios) within SIU Guaraní, which lets an agent distinguish it from partial-status siblings like guarani_estado_cursada or guarani_progreso_carrera. It does not name those siblings explicitly, so it stops short of a 5.

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 word 'completo' implicitly signals that this tool returns the full transcript rather than a partial view, which is a weak cue for choosing it over guarani_progreso_carrera or guarani_estado_cursada. There is no explicit when-to-use, when-not-to-use, or alternative named.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds only the side effect that PDFs may be auto-downloaded when requested; it says nothing about where files land, whether the query is scoped to the authenticated student, or pagination.

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?

A single well-formed sentence with zero padding, front-loading both the resource and the notable download option.

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 simple read-only, two-optional-parameter tool with a fully documented schema and no output schema, this is nearly sufficient: it names the source system and the kind of records returned. Only ambiguity about result shape/scope (own history only? all carreras by default?) keeps it from a 5.

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 parameters are fully documented in the schema; baseline is 3. The description adds no extra semantics beyond the schema (it never explains that 'carrera' filters the history by degree program).

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?

Uses a specific verb ('Consulta') with a precise resource ('historial de solicitudes de constancias y certificados emitidos en SIU Guaraní') and mentions the optional PDF download. It does not explicitly distinguish itself from the nearest sibling, guarani_certificado_alumno_regular, which likely creates/requests a certificate rather than listing past ones.

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?

Usage is only implied: an agent can infer this is the tool for reviewing previously issued certificates, but there is no explicit 'use this when...' statement nor a pointer to the sibling that handles new certificate requests.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the upstream source (SIU Guaraní) and the fact that results are structured, but says nothing about cache/freshness behaviour (only the schema mentions the 45-60s cache) or what happens when the source is unavailable.

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?

Two tight sentences: the core capability leads, and the filter/use-case note follows. The enumerated return fields are dense but earn their place by telling the agent what comes back in the absence of an output schema.

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 three optional parameters, full schema coverage and no output schema, the description covers what the tool returns and how to narrow it. The remaining gap is minor: it does not say whether the query is scoped to the authenticated student or whether 'carrera' must be supplied for multi-career users.

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 100%, so all three parameters are already documented, including the 'hoy' token and the cache-bypass flag. The description only echoes the day-filter idea without adding semantics (e.g., whether 'carrera' is needed when the student is enrolled in several), so it stays at the baseline.

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 ('Consulta el horario semanal de clases') and enumerates the returned fields (día, inicio/fin, aula, comisión) plus the data source (SIU Guaraní). It does not explicitly differentiate from siblings such as guarani_cronograma_evaluaciones or eva_cronograma, which an agent might confuse with a weekly class schedule.

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 quoted natural-language trigger '¿qué tengo hoy?' gives a concrete usage cue, and the day filter is described. However, there is no guidance on when to prefer this over the evaluation-cronograma sibling or how it relates to the weekly-resumen sibling — usage is implied rather than stated.

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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=false, so the safety profile is known. The description adds genuine value by disclosing that the call runs a two-phase cycle with user confirmation, but it never explains what each phase does, whether a confirmation token must be passed, or whether an existing inscription can be overwritten.

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?

A single sentence with the action and target front-loaded and no filler. It is efficient, though the unexplained 'ciclo en dos fases' clause costs it a point since it raises a question the description never answers.

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 destructive, non-idempotent mutation with no output schema, the description should explain what the two phases are and what the tool returns after the first one. Mentioning the two-phase flow and confirmation is a useful start, but the mechanics an agent needs to invoke it correctly are 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?

Schema description coverage is 100%, so all three parameters are already documented, including where llamado_id comes from. The description adds nothing about parameter meaning, so it sits at the baseline for schema-complete inputs.

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 concrete verb plus resource ('Inscribe a examen final en SIU Guaraní'), which separates it from read-only siblings like guarani_mis_inscripciones_examen and guarani_mesas_disponibles. It doesn't explicitly name those siblings as alternatives, and the trailing 'ciclo en dos fases' phrase is opaque rather than clarifying.

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 statement of when to use this versus the listing tools, and no explicit prerequisites in the description itself (the dependency on guarani_mesas_disponibles for llamado_id lives only in the schema). The mention of user confirmation is behavioral, not routing guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds meaningful semantics — the result is computed from the prerequisite graph plus regularized/approved statuses, not stored directly — but omits what the result looks like and what happens when 'carrera' is omitted (0 required parameters), which is real behavioral information an agent needs.

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?

A single sentence, front-loaded with the action ('Calcula qué materias...'), with the qualifying conditions following compactly. No filler or repetition, though it is dense in one long clause rather than structurally separated.

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?

Minor, but note: with no output schema and an optional parameter, the description stops at explaining the computation's inputs. It never indicates the shape of what comes back (list of subject names/codes, with or without reasons) or the default career when 'carrera' is absent, so an agent must probe the response rather than plan for 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 100% and the single parameter is already documented as career name or code. The description does not reference the parameter at all, so it adds nothing about format, default behavior when omitted, or whether it accepts both name and code — the schema must carry that burden alone. Baseline 3 is appropriate.

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 verb and resource: it calculates which plan subjects the student may enroll in next period, based on the correlativity graph and on regularized/approved subjects. That is materially more specific than 'get enabled subjects' and makes the tool's computation distinguishable from data-retrieval siblings. It does not, however, name a sibling it is not (e.g. guarani_correlatividades_y_plan or guarani_plan_optimo), so the boundary is only implicit.

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 'próximo período' framing implies the situation in which an agent should call this, but there is no explicit 'use when X, use Y instead' guidance, no prerequisite about the student having to be logged in or have a plan assigned, and no exclusion relative to the several prerequisite/plan siblings in the toolset.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the parser is experimental pending anonymized HTML fixtures — but says nothing about failure modes, partial results, or what happens when no active turnos exist.

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?

Two compact sentences, front-loaded with the experimental warning. The [EXPERIMENTAL] marker is duplicated across the title, the description opener and the second sentence, which is mild redundancy but the text remains tight.

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 read-only tool with full schema coverage this is nearly adequate, but with no output schema the field list is the only hint at return shape, and an experimental parser that can fail should say what an agent sees on failure or empty results. Missing that, the definition is minimum viable.

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 all three parameters (carrera, materia, forzar_refresco with its 45-60 s cache note) are documented in the schema. The description adds no semantics beyond that, so the baseline of 3 applies.

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 names the resource (mesas de examen final) and enumerates what it returns: fechas, turnos, tribunales y condición, in SIU Guaraní. It is clear what the tool does, but it lacks a leading verb and never distinguishes itself from close siblings such as guarani_mis_inscripciones_examen or guarani_cronograma_evaluaciones.

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 statement of when to use this versus the sibling exam-related tools, no prerequisites (e.g. must be logged in, must have an active turno), and no exclusions. The [EXPERIMENTAL] tag hints at caution but gives no decision rule.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds useful scope cues ('activas', 'actuaciones provisorias'), but says nothing about the caching behavior (the 45-60 s cache is only disclosed in the schema) or what is returned.

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?

A single front-loaded sentence with no filler that states the resource and scope immediately. Appropriate length for a read-only lookup 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?

For a two-optional-param read-only tool with no output schema and annotations covering safety, the description is minimally adequate. It does not indicate what the result contains (mesa, fecha, estado, condición de provisoria) or what an empty result means.

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 both parameters (carrera, forzar_refresco) are fully documented in the schema, including the cache semantics. The description contributes no additional parameter meaning, so the baseline 3 applies.

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 (consulta) and resource (inscripciones activas a mesas de examen final y actuaciones provisorias) scoped to the student. It is distinguishable from guarani_mesas_disponibles (offerings) and guarani_inscribir_examen (action), but never names those siblings explicitly.

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?

Usage is only implied by the phrase 'inscripciones activas... del alumno'; there is no explicit statement of when to prefer this over guarani_mesas_disponibles or guarani_inscribir_examen. An agent must infer the routing from the names alone.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered and the description does not contradict it. What it adds is the deterministic nature of the computation (transitive closure over the prerequisite graph), but it says nothing about data dependencies, what happens when the student's current state is incomplete, or how the estimation is bounded.

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?

A single dense sentence with the action front-loaded and no filler; every clause carries a distinct computational output. It leans slightly jargon-heavy ("cierre transitivo", "altura del camino crítico") which may cost a non-specialist agent, but nothing is wasted.

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 no output schema, the description carries the return-value burden and does partly deliver by enumerating the three outputs (ranking, critical-path height, minimum semesters). It is still incomplete for a tool with all-optional inputs: nothing explains what happens if carrera is omitted, nor the assumed baseline state of the student's cursada.

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 both parameters are documented in-schema, including the default of 5 and the 1-10 range, so the baseline applies. The description adds no semantics beyond the schema, and does not address the notable fact that carrera is optional (0 required), leaving the no-argument behavior unexplained.

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?

Precise verb pair ("Rankea ... y calcula") applied to a specific resource (materias habilitadas + grafo de correlatividades), with the metric named explicitly (cierre transitivo de materias desbloqueadas). It never differentiates itself from the adjacent siblings that also expose habilitadas/correlatividades data (guarani_materias_habilitadas, guarani_correlatividades_y_plan), so an agent cannot rule those out from the description alone.

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?

When-to-use is only implied: an advisory ranking of next-cuatrimestre options emerges from the wording, but there is no explicit trigger case, no stated prerequisite (e.g. requires the student's academic history), and no named alternative to prefer for plain listing or graph inspection. The agent must infer selection from the purpose sentence.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds that the calculation is exact and enumerates what is reported (approved, in-progress, pending by year), but says nothing about data freshness, whether it requires an active Guaraní session, or what happens when no career is specified.

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?

A single front-loaded sentence with the key promise ('Te faltan X materias') up front and no filler. It is dense but every clause maps to real output content; minor tightening would make it a 5.

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 no output schema, the description usefully enumerates the returned figures (remaining, approved, in-progress, per-year breakdown), which is the main completeness burden here. The one gap is the behavior when the optional 'carrera' parameter is omitted, plus no routing against similar academic-history siblings.

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 there is only one parameter, so the baseline is 3. The description never mentions 'carrera', nor that it is optional (0 required parameters) — presumably defaulting to the student's active career — which would have been valuable added meaning.

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 ('Calcula') and a well-defined resource: remaining subjects to graduate, approved/in-progress counts, and pending breakdown by year. An agent can picture the exact output. It does not, however, distinguish itself from overlapping siblings such as guarani_historia_academica or guarani_plan_optimo, which likely return related academic data.

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 use case ('cuántas materias te faltan para recibirte') is clearly implied, so an agent knows when this tool is relevant. There is no explicit when-not guidance and no sibling is named as the alternative for related questions, leaving the boundary with historia_academica/estado_cursada to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description's value-add is naming the four probe areas (including network connectivity and disk paths), but it omits whether prior authentication is required, how long probing takes, and how partial failures are handled.

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?

A single front-loaded sentence enumerating the audited areas with zero filler. Nothing is repeated from the annotations or schema, and every clause adds 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?

For a zero-arg read-only tool the description is close to sufficient, but there is no output schema, so the burden of explaining what the diagnostic returns (per-check pass/fail report? free-text log?) falls on the description and is left unaddressed. Prerequisites such as needing an active session are also unstated.

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 takes zero parameters, so there is nothing for the description to disambiguate and no schema gap to compensate for. Baseline 4 applies; no parameter-level semantics are needed or missing.

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 ('audita') plus the exact facets inspected: connectivity, encrypted session state, graphical environment validity, and storage paths. That is far more informative than a tautology and distinguishes it from the data-retrieval siblings, though it never explicitly explains how it relates to session tools like uca_iniciar_sesion even though it touches 'estado de sesión'.

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 when-to-use, when-not, or alternative named; the agent must infer that this is a pre-flight/troubleshooting check to run before or when other EVA/GUARANI calls fail. The diagnostic framing makes that inference reasonably safe, but the description does no work to route the agent.

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?

Annotations declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, and the description is consistent with all three while adding real context: it opens a browser window, returns a SESION_ACTIVA sentinel instead of launching the browser when a session exists, and that session renewal happens implicitly elsewhere. It stops short of describing what happens on login failure, timeout, or user cancellation in the browser flow.

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 the action, then the sentinel behavior, then the 'no need to pre-call' warning, then the trigger conditions. No filler and no repetition of the title.

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 one optional parameter and no output schema, the definition covers the invocation decision and the sentinel return fully. It leaves open the success return value and failure/timeout outcomes of the browser flow, which the absent output schema would otherwise have carried.

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 100% and forzar_relogin is fully documented in the schema, including its purge behavior and the @uca.edu.ar constraint. The description only alludes to it indirectly via 'cambiar de cuenta', so it adds no syntax or format detail beyond the structured field.

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 ('inicia o renueva la sesión institucional') plus the mechanism ('abriendo el navegador'), which cleanly separates it from every sibling, all of which are data-query tools. An agent can identify this as the auth/bootstrap tool without opening the 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?

Explicitly states when NOT to call it ('NO hace falta llamarla antes de consultar: cada herramienta renueva la sesión sola') and the two narrow conditions that do trigger it ('error de sesión expirada' or the user asking to log in / switch account). This is a textbook when/when-not/alternative disclosure.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds that retrieval happens in parallel across multiple backends, which is genuinely useful context, but it says nothing about authentication/session prerequisites (the uca_iniciar_sesion sibling hints at a login requirement) or what happens when one source fails.

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?

A single dense sentence with the source list front-loaded and no redundancy. The 'Tool Compuesta:' prefix is slightly meta but earns its place by signalling aggregation.

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 tool merging five data sources with no output schema, an agent still lacks the shape of the returned summary, whether sections are omitted or null when a source is empty, and the auth/session requirement. The source enumeration is complete, but the operational details are thin.

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?

Only one optional parameter and the schema documents it at 100% coverage ('Nombre o código de la carrera (opcional)'), so the baseline is 3. The description never mentions the carrera filter or what it scopes, adding no meaning beyond the schema.

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 ('Trae en paralelo') and enumerates exactly which resources it aggregates from EVA and Guaraní (tareas próximas, avisos, cursada/inasistencias, clases de hoy, inscripciones a finales). The label 'Tool Compuesta' signals it is an aggregator over sibling tools, though it never names those siblings explicitly to draw the contrast.

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 explicit when-to-use / when-not guidance. The 'Semanal' framing and 'Compuesta' prefix imply it is a periodic aggregate instead of calling the individual sibling tools, but the agent must infer that; nothing says to prefer this over eva_entregas_proximas or guarani_estado_cursada, or when the granular tools are still needed.

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