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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only retrieval, but says nothing about authentication requirements, ordering, pagination, or how many announcements are returned, which matters for a listing 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 sentence with no filler that front-loads the resource and its scope. It is efficient, though it is terse to the point of omitting guidance rather than being optimally structured for a tool with a filter parameter.

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?

Because an output schema exists, return-value explanation is not required, and for a simple listing tool the description is minimally sufficient. However, the undocumented 'dias' parameter and the absence of any routing guidance against sibling tools leave real gaps.

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

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

The single parameter 'dias' has 0% schema description coverage and a default of 7, so its meaning must come from the description — but the text only says 'Últimos' without explaining that the window is expressed in days. The link between the parameter and the recency scope is left to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (announcements from teachers in each course's notice forum) and a scope (most recent), so an agent understands what it retrieves. It does not explicitly contrast itself with the nearby siblings uned_foros or uned_novedades, which is the main gap.

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

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

There is no statement of when to call this versus alternatives, even though uned_foros and uned_novedades appear to cover adjacent ground. The only implied guidance is the word 'Últimos', which hints at recency but sets no condition.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses the useful constraint that it searches 'materiales descargados' (downloaded content only) and describes the return format, but says nothing about permissions, scope limits, or whether it is read-only.

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 with zero filler. The core purpose is front-loaded and the usage cue follows immediately, with nothing redundant.

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?

An output schema exists, so return values need not be detailed further, and the description covers purpose and usage adequately. However, with three undocumented parameters and no annotations, the definition leaves real gaps an agent must guess at.

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

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

Schema description coverage is 0% and none of the three parameters (consulta, limite, asignatura) are explained in prose. The description does not compensate for the gap: the agent cannot tell what 'asignatura' filters on or what 'limite' controls beyond the default value of 8.

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 ('Búsqueda de texto completo en tus materiales descargados') and even describes the return shape (fragments with file and page for citation). It is clearly a search tool, distinct from read-oriented siblings like uned_leer or uned_materiales, though it does not explicitly name those 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?

Gives explicit usage context: 'Úsala antes de explicar o resumir algo del temario', which tells the agent when this tool is the right choice. It lacks any when-not condition or named alternative tool, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full load. It usefully discloses the destination path and the .ics format with its interoperability target, but says nothing about overwrite behavior, whether the file is created or appended, auth requirements, or refresh semantics for a file-writing operation.

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

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

A single front-loaded sentence with the verb first, the sources enumerated, and the output location appended. Every clause earns its place with 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?

For a zero-parameter tool with an output schema present, the description supplies enough: what is exported and where. The only gap is the write/overwrite behavior of the target file, which the output schema cannot cover.

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

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

The tool takes zero parameters, so the baseline is 4. Nothing in the description needs to compensate for undocumented inputs, and the schema is fully self-describing by virtue of being empty.

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 ('Exporta') and enumerates the resources it aggregates (entregas, eventos, clases/jornadas), placing the output at a concrete path. It's clearly distinguishable from sibling source tools, though it doesn't explicitly name them as alternatives or data sources.

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 ('importable en Google/Outlook') implies the use case — feeding a calendar app — but there is no explicit when-to-use vs alternatives guidance, no prerequisites, and no note on when this should be preferred over reading the individual 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?

No annotations exist, so the description carries the full burden. It does disclose useful traits: classes may be online or in-person, and access credentials/details are included only if the schedule provides them. It omits error behavior, what happens if sync was never run, and any limits, so disclosure is partial rather than rich.

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

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

Two sentences with the resource front-loaded, no filler, and the sync prerequisite placed after the main purpose. Efficient and well-ordered, though not maximally tight.

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

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

An output schema exists, so return-format detail is unnecessary, and the sync requirement is covered. However, with two entirely undocumented parameters and no annotation support, the definition stops short of what an agent needs to invoke it with correct arguments.

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

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

Schema description coverage is 0% and neither parameter is mentioned. The description never explains that 'asignatura' filters by subject/course or that 'incluir_pasadas' toggles inclusion of past sessions, so it does not compensate for the total absence of parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (clases, jornadas, sesiones) with the fields it returns (day, time, teacher, online/in-person), which is concrete and concrete enough to distinguish from generic event tools. It does not, however, name or differentiate itself from close siblings like uned_eventos or uned_calendario_ics, leaving the agent to infer which schedule tool applies.

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 one genuine precondition – 'Requiere haber sincronizado' (must have synced first), implicitly pointing at uned_sincronizar. It offers no when-to-use/when-not guidance and no routing to alternatives among the many schedule-adjacent siblings, so the usage context is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no read-only confirmation, no auth/enrollment prerequisites, no pagination or size behavior for course content. One short noun phrase is inadequate for a data-retrieval tool with zero annotation coverage.

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 cross-reference to uned_cursos is placed where it is immediately useful. It is efficient, though so terse that it borders on under-specification rather than true conciseness.

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?

An output schema exists, so return-value description is unnecessary, and there is only one required parameter. Still, the description leaves the read-only/mutation character and any access prerequisites unstated, which for a zero-annotation tool is a real gap an agent must guess around.

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

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

Schema coverage is 0%, so the description must compensate for the sole parameter. It does add value by stating the courseid must come from uned_cursos, but it never clarifies the expected type, format, or that the value is an integer course identifier as opposed to a name or slug.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource and scope: the sections and resources belonging to one specific course. It does not give an explicit verb (get/list), but the noun phrase clearly identifies what an agent would retrieve and distinguishes it from sibling course-level tools like uned_cursos.

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 '(usa el id de uned_cursos)' points the agent at the sibling tool that supplies the required courseid, which is useful routing. However, it gives no condition for when this tool is the right choice versus siblings like uned_materiales or uned_ficha, and no exclusions.

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

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

No annotations are provided, so the description carries the full burden. It implicitly scopes to the user's own data ("tus cursos") but says nothing about authentication requirements, whether the call is read-only, rate limits, or behavior when no courses are enrolled.

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 optional-output caveat ("si existe") is compact. Nothing is wasted, though it is arguably under-specified rather than genuinely concise.

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

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

For a zero-parameter listing tool with an output schema, the description covers purpose and roughly what is returned, so return-format detail is not required. However it omits any routing guidance against the many sibling tools and any auth/read behavior context.

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 is 4. The parenthetical field list adds marginal value but there are no parameters whose semantics could be unclear.

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 ("Lista") and resource ("cursos matriculados"), plus the fields returned (nombre, id, progreso). It is clearly distinct from siblings like uned_plan or uned_curso_contenido, though it never names an alternative 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 guidance on when to use this tool versus siblings such as uned_curso_contenido or uned_plan. Usage is left entirely to inference from the tool name and the word "matriculados".

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

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

With no annotations, the description must carry the behavioral burden. It conveys useful scope (all courses, forward-looking window) but never states that this is a read-only query, nor anything about authentication, rate limits, or ordering of results.

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 scope and time window with no filler. Nothing is repeated from the schema and every clause 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 one-parameter, read-only query tool with an output schema that defines return values, the description covers what the tool returns and the time window. Only the read-only nature and any ordering/pagination behavior are left unstated.

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

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

The single parameter 'dias' has 0% schema description coverage and only a default of 30. The description supplies its meaning by tying it to 'próximos N días', which is the key semantic the schema omits, though it does not state units explicitly (days are inferable from context).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (entregas/tareas) and the scope (next N days, all courses), so an agent can tell it returns upcoming assignment deadlines rather than calendar events or grades. It does not explicitly distinguish itself from similar siblings like uned_calendario_ics or uned_eventos.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is named for overlapping queries such as deadlines vs. events or the ICS calendar. The intended usage is only implied by the phrase 'próximos N días'.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one behavioral fact — results are forward-looking, limited to the next N days — but says nothing about read-only nature, authentication requirements, timezone/date handling, or whether past or canceled events appear.

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, front-loaded with the resource and the constraint, and the parenthetical examples add disambiguation without bloat. Nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the tool is simple (one optional parameter). Still, the description omits the parameter default and gives no sibling routing, which matters in a 21-tool namespace where it overlaps uned_entregas and uned_clases.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'dias' parameter. 'Próximos N días' does map the parameter to a window length, but it omits the default of 30 days and any bounds or format constraints.

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 (eventos del calendario) and scope (próximos N días), with parenthetical examples (entregas, exámenes, tutorías) that make the content concrete. However, it does not differentiate itself from closely overlapping siblings such as uned_entregas, uned_clases, or uned_calendario_ics, so an agent must infer which one to pick.

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 only states what the tool returns; it never says when to use this versus uned_calendario_ics, uned_entregas, uned_clases, or uned_plan. With 21 sibling tools in the namespace, the absence of any routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one meaningful side effect ('También se guarda en ficha.md'), but says nothing about auth/login requirements, whether the operation is read-only or mutating beyond the file write, or rate/aggregation behavior.

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

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

A single dense sentence lists the covered content, followed by a short side-effect note about ficha.md. It is front-loaded and free of filler, though the enumeration is long and could be grouped more cleanly.

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?

An output schema exists, so return-value explanation is not required, yet the description restates the payload contents while omitting the parameter format and any routing guidance among many similar siblings. It is adequate but leaves clear gaps for a 1-param tool in a crowded toolset.

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

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

Schema coverage is 0% and the single 'asignatura' parameter has no description in the schema. The description only repeats the word 'asignatura' without clarifying expected format (course code, name, ID) or constraints, so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates the concrete contents of the 'ficha' (teaching team/contact, dates and submissions with status, evaluation, statements, syllabus with progress, materials, bibliography, announcements), so an agent knows what resource is being fetched. The verb is only implied (a noun phrase, not 'fetch/aggregate'), and it never distinguishes itself from overlapping siblings like uned_entregas, uned_materiales, or uned_anuncios.

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

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

There is no statement of when to use this tool versus alternatives such as uned_curso_contenido or the specialized uned_entregas/uned_anuncios tools, and no prerequisites or triggers. The agent must infer usage purely from the content list.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read-only listing scoped to 'recent' debates across all forums, which conveys basic behavior, but says nothing about pagination, result limits, or authentication requirements. The 'recientes' framing is the only scope signal 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?

A single front-loaded sentence with no filler; the scope (all forums of a subject) leads immediately. It is perhaps overly terse, but nothing is wasted.

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

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

An output schema exists, so return values need not be explained. However, for a tool with 2 parameters at 0% schema coverage, the description leaves the 'dias' window and the exact meaning of 'asignatura' identifier unresolved, which is a meaningful gap.

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

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

Schema coverage is 0%, so the description must compensate for both parameters. 'Asignatura' is implied by 'de una asignatura', but the 'dias' parameter (default 30) is never explained — 'recientes' only vaguely gestures at it, leaving the time window undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (recent debates across all forums of a subject) and enumerates the content types included (avisos, dudas por tema, estudiantes). It is clear and distinct enough from siblings like uned_anuncios, though it never explicitly names or contrasts an alternative.

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

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

There is no statement of when to use this tool versus alternatives such as uned_anuncios or uned_novedades, which likely overlap in content. The agent must infer the appropriate context entirely on its own.

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

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

With no annotations, the description carries the full burden, and it does disclose a meaningful side effect beyond writing a file: the note is also linked into 'la ficha' (i.e., it mutates another resource). However, it says nothing about overwrite behavior, permissions, or failure modes, leaving significant behavioral gaps.

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

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

A single well-formed sentence that front-loads the action and packs in format, location, and the linking side effect with no wasted 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?

An output schema exists, so return values needn't be explained. Still, for a mutation tool with no annotations and zero parameter documentation, the description omits overwrite/error behavior and leaves one of three parameters undefined, which is only marginally sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: 'asignatura' is revealed as a directory segment in the path and 'contenido' is framed as Markdown study content. But 'nombre' is never explained (filename vs. title) and no formats or constraints are given.

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 (Guarda) plus the resource (resumen, esquema, test o apunte en Markdown) and even the storage path convention (<asignatura>/apuntes/). It is clear what the tool does, though it doesn't explicitly distinguish itself from adjacent siblings like uned_materiales or uned_leer.

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 named alternative. The agent must infer from context that this is for persisting study notes rather than reading or fetching existing materials.

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

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

No annotations are provided, so the description carries the full behavioural burden. It discloses that the tool reads previously extracted text and accepts an optional page range, but says nothing about truncation behaviour despite max_caracteres defaulting to 30000, nor about what happens when the requested range exceeds the material. Read-only safety is only implied by 'Lee'.

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

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

Two compact sentences, front-loaded with the action and the input contract, with the citation instruction appended as a single clause. No filler or repetition; slightly terse given the amount of undocumented surface it is the sole source for.

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?

An output schema exists, so return-shape explanation is not required, and the page-range plus input-provenance statements are useful. However, with no annotations and 0% schema coverage, the unexplained max_caracteres parameter leaves a real gap for a tool an agent will call with variable-length results.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It explains 'archivo' (relative path from uned_buscar/uned_materiales) and the page range ('opcionalmente un rango de páginas'), covering three of four, but leaves max_caracteres entirely undefined — its truncation semantics are absent from both description and 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+resource ('Lee el texto extraído de un material') and immediately anchors it among siblings by naming the source of its input ('ruta relativa devuelta por uned_buscar/uned_materiales'). An agent can tell this apart from the search/listing tools without opening any schema.

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

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

Gives clear context for invocation: the 'archivo' argument must come from uned_buscar/uned_materiales, and usage is optionally narrowed by page range. It also prescribes a downstream behaviour ('Cita siempre archivo y página'). No explicit when-not-use or exclusion is stated, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the browser side effect, that a token is persisted, and that the user's password never passes through the code (a meaningful security guarantee). It omits token lifetime details and behavior if a session already exists, so not a perfect 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 followed by the trigger condition and the security reassurance. 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?

For a simple parameterless login tool with an output schema, the description covers purpose, invocation timing, and key side effects adequately. Only minor gaps remain around token persistence details, which the output schema likely covers.

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 per the rubric the baseline is 4. There is nothing for the description to clarify 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 states a specific verb and resource: it opens a browser to perform SSO login and saves the token. This is unambiguous and clearly distinct from the sibling uned_logout and the other read/write UNED tools.

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 explicit when-to-use guidance: run it once, or again when the token expires. It does not name alternative tools or state when-not to run it, but for a login entrypoint the trigger condition is fully covered.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the token and session are destroyed and that they are local to this machine, but says nothing about whether a server-side session is invalidated, whether the user must be logged in first, or whether the action is reversible.

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; every element (what is deleted, and where it lives) 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 zero-parameter tool with an output schema, the description covers the essential action and its local scope. The only missing piece is the relationship to uned_login and any post-logout state, which keeps it short of complete.

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

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

The tool takes zero parameters, so the baseline of 4 applies; the description cannot add parameter meaning and none is needed. Schema coverage is 100%.

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 (borra) and specific resources (el token y la sesión) with a scope qualifier (guardados en este ordenador). It is unambiguous about what it does, though it never names its natural counterpart uned_login to sharpen the distinction.

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

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

No explicit when-to-use or when-not-to-use guidance and no alternative named (e.g., 'usa uned_login para volver a iniciar sesión'). Usage is only implied by the self-evident semantics of logout.

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

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

With no annotations, the description carries the burden and does disclose that materials are 'descargados' (previously downloaded) and that results include page counts and an extracted-text path, implying a read-only listing. However, it does not state side effects, permissions, or whether it triggers downloads.

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 resource and the returned fields are stated 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?

An output schema exists, so return values need not be explained, and the description still names the key fields. For a simple single-parameter query tool the definition is nearly sufficient, missing only parameter format and usage alternatives.

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

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

Schema coverage is 0%, so the description must compensate. It does identify that the subject (asignatura) scopes the query, but gives no format guidance (course code vs. name, casing) for a string parameter that has no schema description.

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 (listar) and resource (materiales descargados de una asignatura), plus hints at returned fields (nº de páginas, ruta del texto extraído). It does not differentiate itself from nearby siblings like uned_curso_contenido or uned_leer, but the purpose 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?

Usage is only implied: an agent can infer it is used to enumerate materials for a given subject. There is no explicit when-to-use vs. when-not, and no mention of alternatives such as uned_curso_contenido or uned_leer for accessing content.

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

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

With no annotations, the description carries the full behavioral burden. 'Publicadas' is the only real disclosure – it implies unpublished grades are excluded – but nothing is said about authentication needs, scope, ordering, or whether this is a read operation. For a tool with zero annotations this is thin.

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?

Five words with no filler, and the key qualifier ('publicadas') is front-loaded. It loses a point for being a bare noun phrase rather than a sentence, which leaves the action itself unstated.

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

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

The tool takes no arguments and has an output schema, so the description needn't explain return values. What remains missing is the minimal framing an agent needs – that this retrieves the user's published grades and how it relates to the sibling progress/assignment tools – leaving it merely adequate.

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

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

The schema defines zero parameters, so the baseline of 4 applies. There is nothing parameter-wise for the description to clarify or compensate for.

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 fragment identifies the resource ('calificaciones publicadas') but supplies no verb, so it never states what the tool does with it – fetch, list, summarize? It is only loosely distinguishable from siblings like uned_progreso or uned_entregas, which also deal with academic results.

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 at all: no indication of prerequisites (login state), no exclusion of the many overlapping siblings, and no hint of when this tool is preferable to uned_progreso or uned_entregas. The 'curso por curso' phrasing hints at a per-course grouping but not at when to call it.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the content categories returned (entregas, eventos, anuncios), but says nothing about the look-ahead window that governs the output, the read-only nature of the operation, or any auth requirement — the temporal behavior is the most important undisclosed trait.

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 with the content scope front-loaded and the use-case trigger second; no filler. It is terse enough that it sacrifices needed detail, but nothing in it is wasted.

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

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

An output schema exists, so return values needn't be explained. However, for an aggregator that overlaps three sibling tools, the absence of any routing guidance and the undocumented "dias" parameter leave meaningful gaps for correct invocation.

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 parameter "dias" has 0% schema description coverage, so the description is the only place its meaning could be explained. "Próximas entregas" hints at a forward-looking window but never states that "dias" controls the number of days ahead, nor mentions the default of 7.

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 resource agregado: "próximas entregas + eventos + anuncios nuevos", which tells an agent exactly what content the tool returns. It implies aggregation via "Resumen", distinguishing it implicitly from the single-purpose siblings (uned_entregas, uned_eventos, uned_anuncios), though it never names them or confirms it supersedes 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?

"Ideal para '¿qué tengo pendiente?'" gives a concrete trigger scenario, which is better than nothing. But it offers no exclusion or alternative guidance — an agent can't tell from the description whether to call this or the three sibling tools individually, nor whether it requires an authenticated session first.

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

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

With zero annotations the description carries the full burden, and it does disclose one important side effect: the plan is written to ~/UNED/plan-semanal.md. However it omits whether an existing file is overwritten, whether login is required, and any rate or cost behavior, so the disclosure is partial.

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 followed by the persistence detail. Nothing is redundant and nothing needs trimming.

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?

An output schema exists, so return values need no explanation, and the destination file is given. Still missing for a generation tool with two undocumented numeric inputs is any note on overwrite semantics, authentication expectations, or how weeks interact with the hourly budget.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and largely does not: 'repartiendo tus horas' hints at horas_semana but never explains semanas, the default values (4 / 10), or whether hours are a weekly total. An agent must guess the units and effect of each parameter.

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 ('Genera un plan de estudio semanal') plus the inputs it weighs: credits, pending syllabus and deadline proximity. No sibling offers plan generation, so no differentiation is needed, but it stops short of the 5-level by not clarifying scope such as which courses are included.

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

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

There is no statement of when to reach for this tool versus the many uned_* siblings (e.g., uned_entregas, uned_progreso), nor any prerequisite such as being logged in. Usage is only inferable from the purpose sentence, which is the definition of 'no 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?

No annotations are provided, so the description carries the full behavioral burden, yet it never states that this is a read-only query, whether authentication is required (uned_login/uned_logout exist as siblings), or what happens when no asignatura is given. It adds no behavioral context beyond the topic of the data.

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 scope statement ('una o todas') comes after the resource definition. It is appropriately sized for the tool's simplicity.

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?

An output schema exists, so return-value explanation is not needed, and the enum of states plus the all-or-one scope covers the essentials. However, with no annotations and a login sibling in the toolset, silence on read-only behavior and auth is a real gap for an agent deciding whether it can call this safely.

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

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

Schema description coverage is 0%, but the description compensates by explaining 'de una o todas las asignaturas', which tells the agent that omitting the asignatura parameter returns all subjects. That is meaningful semantics the bare string/default schema does not convey.

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 the resource (study status per topic) and enumerates the five possible states (pendiente/leyendo/visto/repasado/dominado), and scopes it to one or all subjects. It does not explicitly name the sibling uned_progreso_marcar or contrast reading versus writing progress, so sibling differentiation is only implicit from the noun-phrase framing.

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 statement of when to call this tool versus uned_progreso_marcar, nor any prerequisites or exclusions. Usage must be inferred from the name and the word 'Estado', which is weak given a near-identical sibling exists.

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

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

With no annotations, the description carries the full burden. It usefully discloses the allowed estado values (pendiente, leyendo, visto, repasado, dominado), which the schema lacks, but it says nothing about permissions, whether the update is reversible, or what happens to a previously set state. Genuine but partial behavioral disclosure.

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: purpose first, then per-parameter hints. No filler. Slightly terse rather than padded, which is the right trade-off 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?

An output schema exists, so return values need not be described, and the estado enumeration is helpful. However, the missing semantics for asignatura and the absence of any usage/routing guidance leave real gaps for a 4-parameter mutation tool with no annotations.

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

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

Schema coverage is 0%, so the description must compensate. It explains tema (name or number, with an example) and nota (optional comment, with examples), and lists estado's possible values, but the required asignatura parameter is left entirely unexplained. Partial compensation only.

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?

Estates a specific verb (Actualiza) plus resource (estado de un tema) and enumerates the valid states, so an agent immediately understands the operation. It is distinguishable from the sibling uned_progreso (which reads progress), though it does not name 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?

The description says what the tool does but offers no when-to-use / when-not-to-use guidance and does not name alternatives such as uned_progreso. Usage is only implied by the verb, and no prerequisites (e.g. login) are mentioned.

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

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

With no annotations the description carries the full burden, and it does disclose the significant side effects well: it writes into ~/UNED, extracts text from files, indexes for search, regenerates fichas/index/calendar, and returns a change report. It still omits auth requirements and whether the operation is reversible or how expensive it is, but the behavioral profile is substantially conveyed.

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?

Front-loads the high-level action, then lists the pipeline steps, then tucks the parameter semantics at the end. Dense but no filler; the trailing parameter notes are slightly list-like but each 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?

An output schema exists, so the return format need not be fully described, and the description still summarizes the change report. For a complex, side-effecting sync orchestration with no annotations, coverage is solid, with auth prerequisites being the main missing piece.

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

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

Schema description coverage is 0% and there are no enums, so the description must compensate — and it does: asignatura is explained as partial name or id (empty = all), and forzar as re-download everything. Both parameters gain meaning unavailable in the bare schema, though the forzar explanation is terse.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource and enumerates the full scope: downloads/updates materials, teaching guide, deadlines and announcements, then extracts, indexes, regenerates and reports. An agent can distinguish this sync/orchestration tool from read-oriented siblings like uned_materiales, uned_anuncios or uned_eventos without opening any schema.

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

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

Usage is implied by the sync semantics and the note that asignatura empty means 'all', which is useful scoping guidance. But it never states when to prefer this over alternatives such as uned_materiales or uned_anuncios, nor any prerequisites (e.g. needing login first), so the agent must infer the routing itself.

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