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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is carried. The description adds useful behavioral content by naming exactly what the call surfaces (balance, eligibility to attend/take exams, in-progress procedures), and the [EXPERIMENTAL] marker warns of instability; it says nothing about authentication, rate limits, or whether historical data is included.

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 domain and then enumerate the returned content; no filler. The only waste is the recurring '[EXPERIMENTAL]' marker, which duplicates the title verbatim.

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 signaling return values, and it does so concretely (saldo, habilitación, trámites en curso). For a zero-required-param read-only tool with annotations covering safety, that is sufficient; only the absence of scope boundaries versus the guarani_* tools leaves a 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% and the single 'consulta' enum is fully self-documenting, so the baseline is 3. The prose indirectly covers all three modes ('aranceles', 'trámites', and implicitly 'todo') but never references the filter parameter or explains default behavior, adding 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?

Names a specific resource domain (aranceles al día/pendientes, estado de trámites administrativos) with a concrete verb (consulta) and enumerates the data returned (saldo, habilitación para cursar/rendir, trámites en curso). The purpose is clear, but nothing distinguishes it from related siblings such as guarani_materias_habilitadas or guarani_mis_inscripciones_examen, which touch on adjacent academic-status 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?

Usage is implied by the scope statement — an agent can infer this is the fees + administrative-procedures tool. However, there is no explicit when-to-use, no negative guidance, and no routing suggestion toward the many guarani_* or eva_* siblings that overlap in the 'habilitación para cursar/rendir' territory.

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 openWorldHint, so safety and determinism are covered. The description adds the scope of indexed content types, but says nothing about result ranking, result volume, or whether search spans all courses when curso_id is omitted — useful context for an open-world search tool.

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 the resource scope precedes the mechanism. It is near-minimal but does not waste words.

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 3-parameter search tool with no output schema, the description is minimally viable. It leaves unanswered whether the search is global by default, how results are ordered, and how it relates to eva_contenido_curso, which an agent would want before choosing it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (query, limite, curso_id) are fully documented in the schema including bounds and defaults. The description adds no extra semantics such as search syntax, accent handling, or what narrowing by curso_id actually filters.

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) and resource set (recursos, consignas y documentos) plus the retrieval mechanism (por palabra clave). This clearly separates it from browse-style siblings like eva_contenido_curso or eva_materias, though it does not name 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: keyword search is the natural signal, so an agent can infer it is for targeted lookups rather than full enumeration. There is no explicit when-to-use/when-not guidance and no pointer to eva_contenido_curso for course-scoped browsing, which is the main ambiguity.

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 openWorldHint, so the safety profile is covered. The description adds only a vague nod to context budgeting ('presupuestar contexto'), but never mentions that results may be large, that caching exists (only surfaced in the schema via forzar_refresco), or anything about latency from hitting EVA directly.

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 what is returned and followed by the filtering capability. No redundant or filler text.

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 listing tool with full schema coverage and no output schema, the description conveys enough about returned entities to call it confidently. It could say more about volume/ordering, but nothing essential 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 description coverage is 100%, so all four parameters, including the section filter and refresh-cache flag, are already documented. The description restates the type/section filtering already in the schema without adding format examples or interaction rules, 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 ('Lista') and enumerates the resource types returned (secciones, módulos, tareas, recursos) scoped to a course in EVA. It is clearly distinguishable from mutation tools, but it does not explicitly contrast itself with overlapping siblings like eva_tareas_y_notas or eva_buscar_materiales.

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 phrase 'para presupuestar contexto' implies this is the broad discovery tool used before narrower queries, but no explicit when-to-use/when-not-to-use or alternative routing is stated. An agent must infer that eva_tareas_y_notas or eva_buscar_materiales should be preferred for targeted lookups.

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 and openWorld, so the safety profile is covered. The description adds one useful behavioral trait—explicitly reporting when no cronograma/programa exists instead of failing silently—but says nothing about extraction limits, file formats handled, or what the returned date list looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste: the first front-loads what is searched and what is extracted, the second covers the no-result path. Nothing is redundant with the schema or annotations.

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-parameter read tool with no output schema, the description covers purpose, extracted data types and the empty-result behavior, which is nearly everything needed. The remaining gap is not routing the agent away from the Guarani-based sibling 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% and the single `materia` parameter is fully documented with examples, so the description need not repeat it; it only references 'una materia' generically. Baseline 3 is appropriate since the schema does all 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?

States a specific verb+resource: searches the syllabus/program file of a course in EVA Moodle and extracts exam, retake and assignment dates. The 'en EVA Moodle' scoping distinguishes it from guarani_cronograma_evaluaciones, but the sibling is never named, so the agent must infer the split itself.

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 by the description (find evaluation dates inside the virtual classroom), and the no-result case is explicitly handled. However, there is no guidance on when to prefer this over guarani_cronograma_evaluaciones or eva_buscar_materiales, which overlap in intent.

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 openWorldHint; "Lectura pura" merely restates the read-only hint rather than adding context. The mention of intentos and calificaciones does reveal what the response contains, but caching behavior (45–60 s) and the fallback scoping are only in the schema, so value beyond structured fields is modest.

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 the read-only marker is placed at the end as a quick qualifier. Slightly dense field listing, but every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity, two-optional-parameter read tool with no output schema and full annotation coverage, the description is sufficient: it names the resource, the fields returned, and the read-only nature. It could be strengthened by noting the cache/fallback behavior, but the schema already carries that.

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 (curso_id fallback behavior and forzar_refresco cache bypass) are fully documented in the schema. The description adds no parameter-level detail, which is acceptable at this coverage level but earns no extra credit.

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 concrete resources (cuestionarios, exámenes parciales online) plus the data returned (fechas de apertura/cierre, intentos, calificaciones), which clearly separates it from eva_tareas_y_notas or eva_foros. It does not name an alternative sibling explicitly, so it falls 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 description says what it retrieves but never states when to prefer it over neighbors like eva_tareas_y_notas or guarani_cronograma_evaluaciones, nor any precondition. The only situational hint (omitting curso_id falls back to active quizzes in the calendar) lives in the schema, not 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 already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the result mixes two kinds of data (deadlines plus 'avisos recientes de cátedra'), which is useful, but it says nothing about ordering, grouping, or how the 30-day cap behaves — that lives only in the 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?

A single front-loaded sentence that names the resource and the default horizon before any caveats. The nested parenthetical '(por defecto 7 días / la semana que viene)' is slightly redundant with the schema default but not wasteful.

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?

No output schema exists, and the tool returns two distinct payload types (due items and notices), yet the description does not say how they are returned or whether either section can be empty. Annotations carry the safety story, but the return-shape gap leaves it only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented and the baseline is 3. The description only restates the default window; it adds no guidance on how curso_id scopes the results or what happens when it is omitted.

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: items with upcoming due dates and recent course notices. An agent can tell it apart from eva_tareas_y_notas or eva_cronograma by the 'próximos días' framing, but the description never names those siblings to make the boundary explicit.

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 parenthetical '(por defecto 7 días / la semana que viene)' implies the typical use case — a weekly look-ahead — but there is no explicit statement of when to prefer this over eva_tareas_y_notas, eva_cronograma, or uca_resumen_semanal, nor any exclusion.

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, openWorldHint and idempotentHint, so the safety profile is covered. The description adds little beyond that, and the parenthetical '(etiquetados con aviso de seguridad)' is ambiguous — it is unclear whether results are filtered to security-flagged messages or merely carry that label. Cache behavior is disclosed only via the schema's forzar_refresco parameter.

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 and resource first and no filler. The trailing parenthetical is the only part that costs clarity rather than earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with full schema coverage and clear annotations, the definition is mostly sufficient, but with no output schema the description should say what each item contains (course, date, flag) and resolve the 'aviso de seguridad' ambiguity.

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% — limit, curso_id and forzar_refresco (including the 45-60 s cache) are all documented in the schema. The description adds no meaning beyond that, 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 two concrete resources ('avisos institucionales' and 'mensajes de foros de cátedra') scoped to the latest items. An agent can tell it apart from eva_hilo_foro (single thread) or eva_responder_foro (write), though the description 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?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as eva_hilo_foro for reading a full thread. The recency wording ('últimos') only hints at the intended scenario.

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

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

The annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the risk profile is structured. The description adds the material context of a required physical confirmation on Canal B, but does not say whether an existing draft is overwritten, what happens to prior submissions, or what a successful response looks like. Given the annotations carry part of the burden, a 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?

Two tight sentences: the verb and mode are front-loaded, and the confirmation requirement follows. The '[EXPERIMENTAL]' prefix duplicates the title, but the body is waste-free. Nothing important is buried at the end.

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 write tool this is thin. No output schema exists, so the description should still address what state change results and how the draft relates to any existing delivery, and 'Canal B' is unexplained jargon. The annotations and full schema coverage carry the rest, so it is adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all three parameters documented inline, including max lengths and the cmid meaning, so the schema does the heavy lifting. The description only implies that file or inline text are the two upload modes. It adds no format or mutual-exclusivity rules beyond the schema, 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 gives a specific verb and resource: uploading a file or text to EVA Moodle as an editable draft. That is clearly distinct from read-only siblings such as eva_tareas_y_notas or eva_leer_archivo. It stops short of naming the upload case that would separate it from other write tools like eva_responder_foro.

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?

It discloses one prerequisite, 'Requiere confirmación física en Canal B', which tells the agent that a human confirmation step is needed before calling. It never says when to prefer this over alternatives, nor when to use ruta_archivo versus texto_en_linea. Usage is only implied by the draft-upload framing.

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, openWorldHint and idempotentHint, so the safety profile is covered. The description usefully adds that replies are included and ordered, but says nothing about pagination, truncation of very long threads, or depth limits – relevant for an open-world read.

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 sentence, zero waste, with the resource and completeness guarantee front-loaded. Nothing to trim and nothing buried.

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 single-parameter read-only tool with annotations and full schema coverage, the description covers what is returned (all replies, ordered). It could go further on thread size or what happens with nested replies, but there is no output schema so the shape statement carries reasonable weight.

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 parameter with 100% schema description coverage, so the baseline is 3. The description's "debate o hilo" phrasing reinforces the schema meaning of discusion_id but adds no format, source, or lookup guidance beyond it.

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 ("Obtiene el debate o hilo completo de un foro") and adds scope (all replies, ordered). It implicitly separates itself from eva_foros (listing) and eva_responder_foro (posting) by emphasizing "hilo completo," though it never names those siblings.

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: use this when you need the full thread rather than a forum listing. There is no explicit when-to-use, no prerequisites, and no named alternative (eva_foros vs eva_responder_foro), so an agent must infer the routing from the purpose statement 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, openWorldHint, and idempotentHint. The description adds useful behavioral context beyond them: downloads are allowlisted to HTTPS, output is text for PDFs/Office or image blocks for scanned files, and resource/folder queries are logged as visualizations on the platform.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tightly written sentences with no wasted text. It front-loads the core behavior and then adds the platform-logging note as a relevant secondary detail.

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 still explains that the tool returns extracted text or image blocks, which is important for an agent. Combined with the fully documented schema and annotations, it is nearly complete, though it could clarify that either url or cmid must be provided.

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 the schema already explains url, cmid, page limits, and cache refresh. The description does not add parameter-level meaning beyond what the schema provides, which is the baseline for fully documented parameters.

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: securely downloads and extracts text from PDFs/Office files, or returns image blocks for scanned files. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as eva_contenido_curso or eva_buscar_materiales.

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 the capability but gives no explicit guidance on when to use this tool versus alternatives. It does not say when to choose file reading over listing course contents or searching materials, so the agent must infer usage from the tool name and schema.

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 openWorldHint, so the safety profile is covered. The description adds the important default-filter behavior (archived courses omitted unless requested), but this largely restates the incluir_archivadas schema description, and it omits any note about caching, which the schema surfaces via forzar_refresco.

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 core purpose, followed by the default-vs-opt-in distinction. There is no filler or repetition beyond the necessary clarification of default scope.

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-boolean, read-only listing tool with no output schema, this is nearly sufficient: it conveys the resource enumerated and that results carry course identifiers. A brief note on return shape (names plus IDs, one entry per enrolled course) 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 both booleans are already documented, and the description's mention of incluir_archivadas adds no new semantics. forzar_refresco and its cache-invalidation contract are not addressed at all in the description, 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: 'Lista las aulas virtuales y materias matriculadas en EVA Moodle con sus identificadores de curso'. It is clearly a course-enumeration tool, distinct from content-level siblings like eva_contenido_curso or eva_tareas_y_notas. It does not explicitly name a sibling or position itself as the entry point that produces the course IDs other tools need.

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 only) and the opt-in for archived/hidden courses, which implicitly tells the agent when to set the flag. However, it names no alternative tool and gives no explicit 'use this before X' guidance, despite being the natural discovery step for the eva_* family.

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?

Beyond the annotations (readOnly=false, destructive=false, idempotent=false, openWorld=true), the description discloses the human-in-the-loop gate: the full text is shown and physical confirmation in Canal B is required before publishing. It does not say whether the reply is publicly visible to the class or error-recoverable, so not a 5.

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 action and resource, followed by the behavioral caveat; nothing is padded. 'Muestra el texto completo' is slightly vague about who sees it, which 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?

For a two-parameter mutation with annotations covering the safety profile and no output schema, the definition covers what the tool does and the confirmation requirement. It omits what the tool returns on success (e.g., post ID or link) and whether the reply is public to the whole course forum.

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 schema already documents both parameters including the 350-character limit and the numeric thread ID. The description only adds that the full message text is displayed for confirmation, which is marginal semantic value over 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: 'Publica una respuesta en un foro de cátedra de EVA Moodle', which is distinguishable from read-oriented siblings like eva_foros and eva_hilo_foro. It does not explicitly name those siblings as the read alternatives, which keeps it just below 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?

Usage is implied (reply to an existing thread) and the description adds a real precondition — the response must be confirmed physically in Canal B — but there is no explicit when-to-use/when-not or named alternative for reading threads first versus replying.

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 openWorldHint, so safety is covered externally. The description adds nothing behavioral beyond that—notably it fails to state that closed/overdue tasks are excluded by default (that fact lives only in the parameter schema), which materially affects what the agent receives.

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. Minor redundancy between 'plazos de entrega' and 'fechas límite' slightly dilutes the precision but the core is delivered 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?

For a simple read-only two-parameter tool with no output schema and full schema coverage, this is minimally adequate. The key gap is that the default exclusion of overdue tasks is not surfaced in the description, nor is the relationship to eva_entregas_proximas clarified.

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%, with both parameters documented including the optional course filter and the incluir_cerradas default. The description adds no meaning beyond the schema, 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 concrete resource set (tareas, plazos, estado de entregas, fechas límite) in EVA Moodle, so the agent knows what it returns. However, it does not differentiate from siblings like eva_entregas_proximas or eva_cronograma, which plausibly overlap with deadlines, and 'plazos de entrega' and 'fechas límite' are near-synonyms rather than distinct concepts.

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 indication of when to use this tool versus eva_entregas_proximas, eva_cronograma, or eva_cuestionarios, all of which appear to touch assignments/dates. The agent must infer selection from the name 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 flag this as non-read-only, non-idempotent and open-world; the description adds genuinely new context: output is a PDF with an institutional validation code, and issuance is gated by a physical confirmation step in 'Canal B'. It doesn't say whether a prior emitted constancia is reused or where the file lands, so it stops short of a 5.

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 deliverable, with the security constraint appended. The parenthetical enumeration of constancia types is slightly compressed but costs little space.

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 six-parameter, zero-required, no-output-schema mutation tool, the description covers what is produced (signed PDF) and the blocking confirmation step. It leaves out how the PDF is delivered and whether a Guaraní session is required, but the essential call context is present.

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 the schema already documents all six parameters including the constancia enum and the 1-5 copy limit. The description only echoes a subset of the enum values (alumno_regular / actividades_aprobadas / promedio) and adds no syntax or format detail, 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 (emite/descarga) and resource (Constancia de Alumno Regular en PDF) plus the variants of constancia covered. It implicitly separates from the 'historial_constancias' sibling by emphasizing issuance/download rather than listing, but 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?

Usage is only implied: an agent infers it should call this when it needs an official certificate. There is no explicit when-not guidance, no mention of how it relates to guarani_historial_constancias, and the 'forzar_nueva' re-emission scenario is only visible through the schema.

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 openWorldHint, so safety is covered. The description adds that supplying a materia triggers a dependency analysis, but says nothing about data freshness, authentication requirements, or how the 'interactive' plan behaves when no parameters are given.

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, both load-bearing: the first states what is returned, the second states the analytic behavior when the key optional parameter is supplied. No filler.

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 only two optional parameters and no output schema, the description gives enough for an agent to call it correctly and understand roughly what comes back. It falls short only on how the two parameters interact and on sibling routing.

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 baseline is 3; the description earns above that by explaining the behavioral effect of the optional materia parameter (blocking prerequisites and dependent future subjects). It still does not clarify carrera's scoping effect or what omitting both parameters yields.

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 (consulta) and concrete resources: el plan de estudios, materias por año, estado de aprobación, correlatividades para cursar y rendir final. It is clear what the tool returns, though it does not explicitly differentiate itself from siblings like guarani_plan_optimo or guarani_progreso_carrera.

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?

It gives one conditional usage hint — 'Si se especifica una materia, analiza qué correlativas la traban y qué materias futuras dependen de ella' — but never states when to prefer this over the several adjacent plan/progress tools. Usage is implied rather than guided.

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 and openWorld, so safety is covered. The description adds the data source (SIU Guaraní) and the default upcoming-only filter, but omits that results are cached for 60s and can be refreshed — that detail lives only in the schema, so no extra behavioral context is added beyond annotations plus the default scope.

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 naming the resource, source and scope, plus one short clause on the default filter. No filler and nothing to trim.

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?

Read-only tool with zero required parameters, full schema coverage and no output schema, so the description only needs scope and default behavior — both present. Minor gap: it doesn't clarify that no career argument means all current courses, which matters for the optional 'carrera' filter.

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. The description reinforces the default filter behavior ('solo las próximas') that maps to incluir_pasadas and notes the returned fields (hora, comisión), but adds no syntax or format detail beyond the schema. 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 resource (official exam/parcial/recuperatorio dates) with scope ('tus cursadas actuales, SIU Guaraní') and returned fields (hora, comisión). An agent can distinguish it from guarani_mesas_disponibles or guarani_mis_inscripciones_examen by the 'official dates for my current courses' framing, though no sibling is named 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?

'Por defecto solo las próximas' implies the default usage and hints that historical data requires a flag, but there is no explicit when-to-use guidance versus the exam-registration or mesas tools that overlap conceptually. 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 readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds that it consults an external institutional system (SIU Guaraní) and clarifies the concept of mandatory/pending surveys, but it does not describe what happens when no surveys exist, whether authentication is required, or what the response looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with no filler. It is appropriately sized for a simple read-only tool, though it stops short of adding task-oriented guidance.

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-parameter, read-only query whose annotations already carry the safety signals, the description is sufficiently complete: the agent understands the resource and the system being queried. The absence of output details is a minor gap given there is no output schema.

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, and the schema already describes it as a name or code with 100% coverage. The description does not add syntax or filtering semantics beyond what the schema provides, 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?

States a specific verb (consulta) and a well-defined resource: whether the student has mandatory or pending institutional teacher surveys in SIU Guaraní. No sibling in the list covers surveys, so the purpose is effectively distinct, though the description does not explicitly contrast with alternatives.

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 never says when to call this tool versus alternatives, nor when not to call it. Usage is only implied by the purpose statement; there is no guidance about prerequisites or 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=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds the meaningful detail that data originates from SIU Guaraní and that accumulated absences and regularity are computed, but it says nothing about authentication needs or how many cursadas are typically 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 that lists the returned content without filler. It is appropriately sized, though it spends its length on output contents rather than on disambiguation, which is the more valuable information here.

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 tool with one optional parameter and no output schema, the field enumeration partially substitutes for a return-value description. Still missing is any distinction from guarani_horario_semanal in the horarios dimension and any statement of default scope when carrera is omitted.

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% for the single optional 'carrera' parameter, so the baseline applies. The description never mentions that results can be narrowed by carrera or what happens when it is omitted (presumably all active cursadas), so it adds no semantics 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 ("Detalla") and enumerates the resource contents: cursadas activas, horarios, regularidad, inasistencias. It does not, however, differentiate itself from close siblings such as guarani_horario_semanal (which also returns horarios) or guarani_historia_academica, 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?

There is no when-to-use guidance, no exclusion of alternatives, and no mention of prerequisites such as having an active SIU Guaraní session. The agent must infer from the name alone that this is the general status view rather than the weekly-schedule or academic-history tools.

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 openWorldHint, so the safety profile is covered. The description adds useful context by enumerating the data categories returned, which partially compensates for the absence of an output schema, but says nothing about authentication prerequisites or whether the whole transcript is returned at once.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, front-loaded sentence that leads with the resource ('Analítico completo') and then enumerates contents. No filler; the only weakness is that the colon-and-list form is a bit terse for an agent needing selection cues.

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 explaining return contents, and it does list the key categories (aprobadas, pendientes, notas, promedios). For a single-optional-parameter read-only tool this is largely sufficient, though it stops short of describing the return structure or the effect of the carrera filter.

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, whose schema description already covers name-or-code semantics at 100% coverage. The tool description does not mention the parameter or explain what happens when it is omitted, so it adds 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?

The description names a concrete resource (the full academic transcript) and enumerates the contents it returns: passed finals, pending subjects, grades and averages from SIU Guaraní. An agent knows what data comes back, but nothing distinguishes it from related siblings such as guarani_progreso_carrera, guarani_estado_cursada or guarani_materias_habilitadas.

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 choose this tool over the many overlapping Guaraní siblings (progreso_carrera, estado_cursada, historial_constancias). The description states content only; the agent must infer the selection condition itself.

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 openWorldHint=true. The description adds useful context that PDF downloads are optional, but it does not explain what the download does, whether authentication is required, or what the returned history contains.

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 wasted language. It states the core action and the optional download behavior efficiently.

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 two-parameter read-only tool with full schema coverage and annotations, the description is largely sufficient. The main gap is that it does not describe the shape of the returned history, but the overall purpose and optional download behavior are clear.

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 already well documented. The description mentions the PDF download option, which corroborates the 'descargar' parameter, but adds no new 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 (consulta) and resource (historial de solicitudes de constancias y certificados) in SIU Guaraní. It is clear what the tool retrieves, but it does not explicitly distinguish itself from sibling tools such as guarani_certificado_alumno_regular, which likely handles new certificate requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for checking past certificate requests and optionally downloading PDFs, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is not the tool for requesting a new certificate.

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 openWorldHint, so the safety profile is covered. The description adds the data source (SIU Guaraní) and returned schedule fields, but it does not itself mention caching or stale-data behavior, even though forzar_refresco covers that in the 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?

The description is two concise sentences with no wasted text. The core purpose is front-loaded and the today-filter hint follows naturally.

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 zero required parameters, full schema coverage, and annotations covering safety, the description is mostly complete. It describes the returned schedule structure, which is valuable because no output schema exists, though it could say more about the optional carrera filter and cache behavior.

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. The description reinforces the 'today' filter but does not add semantics beyond the schema for dia, carrera, or forzar_refresco, 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?

States a specific verb and resource: consulting the weekly class schedule from SIU Guaraní, and lists the returned fields (day, start/end time, classroom, commission). It is clear what the tool does, but it does not explicitly distinguish itself from nearby schedule-related siblings such as guarani_cronograma_evaluaciones 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?

The description implies usage by mentioning the weekly class schedule and the today-filter use case ('¿qué tengo hoy?'), but it does not state when to use this instead of alternatives or any exclusions. Guidance is present but implicit.

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=true, so safety is covered elsewhere. The description adds partial behavioral context by revealing a two-phase cycle and an out-of-band physical confirmation in 'Canal B', but neither is explained: it never says whether an interrupted phase leaves a half-enrollment or what happens on a repeat call.

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 action is stated first. It loses a point because unexplained jargon ('ciclo en dos fases', 'Canal B') occupies the second half instead of actionable detail.

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 write operation with no output schema, the description omits what the two phases are, what the physical confirmation entails, what a partial success looks like, and whether the enrollment can be undone. Critical decision information for an agent about to mutate state 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 description coverage is 100%, so all three parameters (carrera, materia, llamado_id) are already documented, including the pointer to guarani_mesas_disponibles for the ID. The description adds nothing about expected formats or how carrera/materia are matched (name vs. code).

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+resource ('Inscribe a examen final en SIU Guaraní'), which clearly separates it from read-only siblings like guarani_mis_inscripciones_examen or guarani_mesas_disponibles. The added qualifiers ('ciclo en dos fases', 'Canal B') are opaque but the core action is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus alternatives, no prerequisites, no note that it should follow guarani_mesas_disponibles (that link only appears inside the llamado_id schema description, not the tool description). The agent must infer the workflow entirely.

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 and openWorld, so safety is covered. The description usefully adds the derivation logic (correlativity graph + regularized/approved subjects), but omits that the student is implicitly resolved from session/auth since the only parameter is 'carrera' — a notable gap for an openWorld tool that presumably reads live academic records.

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 states the computation, the criteria, and the scope without filler. Nothing to trim.

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?

No output schema exists, so the description is the only signal of return value, and 'qué materias ... está en condiciones de cursar' only implies a list without saying what fields or reasoning accompany each subject. It also leaves the implicit-student/session requirement unstated, which matters for an openWorld read of live records.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With one parameter at 100% schema description coverage, the schema already explains 'carrera' as name or code. The description only indirectly connects it to the 'plan de estudio', adding marginal meaning beyond the schema; 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 output ('Calcula qué materias ... está en condiciones de cursar') plus the input basis (grafo de correlatividades, materias regularizadas o aprobadas). This is clearly distinguishable from siblings like guarani_correlatividades_y_plan (which shows the graph) and guarani_plan_optimo (which optimizes the plan), even though it doesn't name 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 'próximo período' framing implies the planning use case, but there is no explicit when-to-use or when-not-to-use guidance, and no referral to the closely related siblings (correlatividades_y_plan, plan_optimo). An agent must infer that this is the eligibility check as opposed to the graph-inspection 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by flagging the parser as experimental and dependent on anonymized HTML fixtures, which warns the agent that results may be unreliable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with the experimental status front-loaded and no wasted text. The second sentence earns its place by explaining why the tool is marked experimental.

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 low-complexity, read-only query with fully documented parameters and no output schema, the description gives a useful summary of returned fields and a reliability caveat. It is not fully complete because it does not route the agent among sibling exam-related 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%, so all three parameters are already documented in the schema, including the cache-refresh behavior of forzar_refresco. The description adds no parameter-level meaning beyond that, which matches the baseline of 3 when the schema carries the parameter 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?

The description identifies a specific resource: final exam boards in SIU Guaraní, including dates, shifts, tribunals, and condition. It is more than a restatement of the name/title, but it does not use an explicit verb such as 'list' or 'query' and does not distinguish itself from sibling exam tools like guarani_mis_inscripciones_examen.

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 use this tool versus alternatives such as guarani_cronograma_evaluaciones, guarani_mis_inscripciones_examen, or guarani_inscribir_examen. The experimental caveat is useful context but is not usage 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, and openWorldHint=true, so the safety profile is covered. The description adds useful data-scope context by specifying "activas" and "actuaciones provisorias," but it does not mention caching behavior or authentication needs, which are relevant given the forzar_refresco parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no wasted words. The core purpose is front-loaded and immediately scannable.

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 low-complexity, read-only tool with two optional parameters and clear annotations, the description is minimally adequate. However, it does not explain the return content or the meaning of "actuaciones provisorias," and there is no output schema to fill that 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%, and both parameters (carrera and forzar_refresco) are fully documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 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 ("Consulta") and resource ("inscripciones activas a mesas de examen final y actuaciones provisorias del alumno"), making it clear this is a read operation over the student's own exam registrations. It does not explicitly differentiate itself from siblings such as guarani_mesas_disponibles or guarani_inscribir_examen, but the scope is otherwise clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance about when to use this tool versus alternatives like guarani_mesas_disponibles or guarani_inscribir_examen. The intended use is only implied by the phrase "inscripciones activas... del alumno," leaving the agent to infer routing among many sibling tools.

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 openWorldHint, so the safety profile is covered. The description adds useful behavioral detail about the computation itself: transitive closure of unlocked subjects, critical-path height, and minimum-semester estimation. It does not discuss data freshness or assumptions, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single dense sentence that front-loads the main action ('Rankea') and then explains the metrics computed. It is efficient, though the parenthetical and stacked technical terms make it slightly harder to parse than an ideal definition.

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 only two parameters, no nested objects, and no output schema, the description does a reasonable job of stating what the tool returns: ranked subjects plus critical-path and minimum-semester estimates. It could be more explicit about the output structure or ordering, but the core computational result is conveyed.

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 already documented in the schema. The description does not add syntax, format, or selection guidance for 'carrera' or 'max_sugerencias' beyond what the schema provides, 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?

States a specific verb and resource: it ranks enabled subjects by their multiplier impact in the prerequisite graph, and additionally computes critical-path height and minimum semesters to graduate. This clearly distinguishes it from a plain listing tool such as guarani_materias_habilitadas, even without naming that sibling.

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 mention of 'materias habilitadas para cursar' and 'próximo cuatrimestre' suggests academic planning, but there is no explicit when-to-use guidance, no prerequisites, and no statement of when to prefer this over guarani_materias_habilitadas or guarani_correlatividades_y_plan.

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 cover the safety profile (readOnly, idempotent, openWorld), so the description's added value is in previewing the computed output: totals, approved, in-progress, and a per-year breakdown. It does not disclose the data source, auth requirement, or what happens when no career is resolvable, which keeps it below a 5.

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 that front-loads the core result ('cuántas materias te faltan') and then enumerates the supporting breakdown. No filler or repetition.

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, one-parameter tool with no output schema, the description goes far by describing the returned metrics. The one gap is that 'carrera' is optional (0 required) and the description does not explain the default scope when it is omitted.

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 single 'carrera' parameter is fully documented in the schema (100% coverage), so a baseline of 3 applies. The description adds nothing about whether the argument is a name vs. code or what defaults to when omitted.

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 computation (counting remaining subjects to graduate) with concrete output examples ('Te faltan X materias'). It's clear what the tool does, but it never names a sibling to distinguish itself from close alternatives like guarani_historia_academica or guarani_plan_optimo, leaving that separation 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?

Usage is only implied by the described output. There is no explicit 'use this when you want X rather than Y' guidance, no prerequisite (e.g., being logged in), and no exclusion against the closely related academic-history and study-plan tools.

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 openWorldHint=true, so the safety and repeatability profile is covered elsewhere. The description adds real value by naming the four probe categories, which tells the agent this reaches out over the network and inspects environment state. It does not disclose what a result looks like, whether failures are returned as errors or as payload fields, or whether it depends on an existing session.

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 zero filler, front-loading the operational verb and then the checked areas in a compact list. It is appropriately sized for a no-argument tool, though the bare noun-phrase enumeration leaves no room for the result-interpretation hint that would justify 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 parameters and no output schema, the description carries the burden of explaining what the agent receives from a diagnostic run — a pass/fail per category, error strings, free text? That is absent, which matters for a tool whose entire value is interpreting its own output. Annotations cover the safety side, so the gap is narrow 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?

The tool takes zero parameters, so the baseline of 4 applies: there is no parameter semantics to add, and the description correctly does not invent any. Nothing is missing on this dimension.

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 ('Audita') and enumerates the exact resources under test: connectivity, encrypted session state, graphical environment, storage paths. That is concrete enough to predict the tool's scope without opening any schema. It loses the top mark only because it never distinguishes itself from the closest sibling (uca_iniciar_sesion), so an agent must infer that this is validation-of-environment rather than authentication itself.

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 when-to-use signal at all: no trigger conditions ('when login fails, or before first session'), no exclusions, and no pointer to the alternative (uca_iniciar_sesion) when the actual need is to log in. The agent is left to guess whether this tool should be called proactively or only after an error.

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; the description adds the crucial behavioral fact that a browser window is opened (an interactive side effect an agent should warn the user about) and that an existing session can be renewed rather than just created. It stops short of saying whether the prior query is retried after login, which would complete the loop.

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 waste: the action is front-loaded and the restrictive usage rule follows immediately. Nothing superfluous.

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 single-optional-parameter auth tool with annotations and no output schema, the description covers action, mechanism and correct timing. The only gap is what the agent should do after login succeeds (e.g., retry the failed query), a small but real omission.

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 schema itself explains that forzar_relogin purges the stored session and browser profile to allow switching accounts. The description mentions the parameter not at all, so it adds nothing beyond the structured field; 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 pair (inicia/renueva) plus the resource (sesión institucional) and the mechanism (abriendo el navegador). No sibling tool touches authentication, so it is trivially distinguishable from the eva_* and guarani_* tools in the list.

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 an explicit, exclusive trigger condition: only after a session-expired error or an explicit user request to log in. The 'ÚNICAMENTE' framing also serves as a when-not-to-use rule, preventing the agent from calling it preemptively.

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, openWorldHint=true and idempotentHint=true, so the safety profile is covered. The description adds only that fetching happens 'en paralelo'; it omits what an agent most needs for a multi-source aggregator — partial-failure behavior, whether missing sources cause errors, and whether auth must already be established via uca_iniciar_sesion.

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 wasted words, and the resource list is packed efficiently. The 'Tool Compuesta:' prefix is slightly meta rather than user-facing, but it does signal the composite nature 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?

For a composite tool with no output schema, the description should at least sketch the shape of the aggregated response or how sections map to sources; it only lists inputs to the aggregation. Adequate to select the tool, but thin for interpreting what comes back.

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 with 100% schema description coverage, so the schema fully documents 'carrera'. The description adds nothing about how that parameter narrows the aggregated sources, which is the baseline 3 case where the schema carries the parameter 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?

The description uses a concrete verb ('Trae en paralelo') plus an explicit enumeration of the five resources aggregated (tareas de EVA, avisos, cursada/inasistencias, clases de hoy, inscripciones a finales). That makes it distinguishable from the granular siblings it bundles, though it never names those siblings directly.

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?

Only implied guidance: the title 'Resumen Semanal' suggests a weekly overview use case, but the description does not say when to prefer this composite over the individual eva_/guarani_ tools or what the trade-offs are (e.g., cost vs. granularity). No exclusions or prerequisites are stated.

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