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

Annotations already declare readOnlyHint=true, but the description adds the non-obvious rule that confirm: true will not enable writes without independent human approval — a critical behavioral fact an agent could otherwise get wrong. It does not describe what the preview returns or any limits, so it falls short of fully rich 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 sentences, zero waste, with the preview scope and the write-blocking caveat both front-loaded. The only mild redundancy is repeating the confirm: true behavior that the schema also states.

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 preview tool with no output schema and full parameter coverage, the description conveys nearly everything needed to call it safely. The one gap is what the returned preview contains, which the agent must discover empirically.

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

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

Schema description coverage is 100%, so every parameter including confirm is already documented; the description's mention of confirm largely restates the schema. Baseline 3 is appropriate given the schema carries the parameter burden.

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 ('Previsualiza un recordatorio personal'), and the second sentence clarifies that no creation occurs, correcting the misleading 'add_event' name. It does not explicitly distinguish itself from the sibling list_calendar_events, though 'personal reminder' vs. Campus calendar implies the split.

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 rather than stated: the tool is for producing a preview, and creation is blocked pending human approval. It never names an alternative (e.g. what to do when the agent actually needs a Campus event), so the agent must infer the fallback path.

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 and destructiveHint=false, but the description adds the critical behavioral fact an agent would otherwise miss: that writes are disabled server-side and confirm: true does not publish. That directly counters the false expectation created by the 'post' verb. It stops short of describing what the preview returns or how validation failures surface.

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 zero filler. The gating constraint is front-loaded and the confirm caveat follows immediately, so the most important information is read first.

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 five-parameter, fully documented, non-destructive tool with no output schema, the description covers the one fact an agent could get wrong (that confirm: true does not publish). What the preview actually returns or how invalid input is reported is left implicit, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, including a detailed explanation of the confirm flag that mirrors the tool description. The description adds no meaning beyond the schema for course_id, forum_id, subject, or message, 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 pair and resource: 'Valida y previsualiza un tema de foro'. It also resolves the ambiguity created by the tool name (forum_post_topic) by clarifying that posting is disabled, so the agent understands this is a validation/preview operation. It does not explicitly contrast with forum_reply, but the resource (topic vs. reply) is distinguishable from 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?

The description establishes the usage context (preview only, publishing blocked pending independent human approval), which is a meaningful when-to-use signal. However, it never states an explicit alternative or next step for actually publishing, nor when to prefer this over forum_reply or get_forum_discussions. Usage is implied rather than prescribed.

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 readOnlyHint=true and destructiveHint=false. The description adds important behavioral context beyond that: publishing is disabled until independent human approval, and confirm: true does not enable posting.

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 concise sentences, with the critical constraint front-loaded. Every sentence earns its place and there is no unnecessary 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 preview-only tool with full schema coverage and no output schema, the description covers the key constraint an agent needs: that it cannot publish even with confirm set to true. Minor detail about the preview return format is absent but not critical.

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 four parameters, including confirm. The description reinforces the confirm semantics but does not add new meaning beyond what the schema provides.

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: previewing a forum reply. This distinguishes it from a publishing tool, though it does not explicitly name or contrast with the sibling forum_post_topic.

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

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

The description implies this tool is for previewing because publication is disabled pending human approval. However, it does not explicitly state when to use this tool versus forum_post_topic or other alternatives.

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 and openWorldHint=true, so safety is covered; the description's added value is enumerating the payload (submission status, dates, teacher attachments), which is meaningful behavioral context given there is no output schema. It stops short of noting the open-world/remote-fetch implication or any error behavior for invalid IDs.

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

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

A single well-formed sentence with the resource up front and the returned fields trailing as enumeration; no filler. Dense but readable, and nothing needs to be cut.

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 tool with full schema coverage and no output schema, the description carries the return-value burden well by listing the returned fields. Missing only guidance on when to prefer it over list_assignments, which is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100% and the single parameter is well documented in the schema itself ('ID numérico ... o URL completa de la tarea'). The description adds nothing about the parameter, so the schema does all the work and 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 and resource ('Obtiene el detalle completo ... de una tarea') and enumerates exactly what detail is returned: consigna, estado de entrega, fechas y adjuntos. The word 'detalle' combined with the enumerated fields implicitly separates this single-item fetch from list_assignments, though the sibling is never named outright.

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 rather than stated: an agent infers this is the single-assignment detail fetch as opposed to list_assignments or submit_assignment, but there is no explicit 'use this when' clause, no prerequisite (e.g. needing an ID obtained from list_assignments), and no exclusion against alternatives.

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 and openWorldHint=true. The description adds the Moodle module context (mod_choice) but does not disclose return shape, whether results are paginated, what an empty result means, or any permissions nuance—low added behavioral value beyond annotations.

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

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

It is a single front-loaded sentence with no waste. However, the sentence does not structure any usage or return-value information, so it is concise but minimal.

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 one-parameter read-only tool with full schema coverage and safety annotations, this is minimally adequate. It lacks explicit routing to submit_choice and gives no hint about the returned options/results, which matters because no output schema exists.

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 has 100% description coverage and explains choice_id as the numeric Moodle choice ID with a view.php URL pattern. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb (consulta) and resource (opciones de una elección/inscripción de grupos, mod_choice), so the agent knows this is a read of choice options. It does not explicitly differentiate from the sibling submit_choice, but the verb contrast makes the distinction reasonably 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 when-to-use guidance, no exclusion, and no mention of the sibling submit_choice as the alternative for answering a choice. Usage is only implied by the verb 'consulta'.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful context about return contents (author, date, Markdown body) but says nothing about thread size, pagination, or truncation behavior for large discussions.

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, scope, and payload are stated immediately. It is appropriately sized, though slightly terse given no follow-up caveats.

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 and no annotations covering data volume, the description should note anything an agent needs about large threads or pagination. It covers what fields come back but leaves that operational gap, 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 coverage is 100% and the single discussion_id parameter is documented with a concrete URL/ID example, so the schema carries the load. The description adds no syntax or format guidance beyond what the schema already provides, making baseline 3 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?

States a specific verb+resource (get all posts and replies of a discussion thread) and what is returned (author, date, Markdown content). It is distinguishable from get_forum_discussions by operating on posts inside a thread, but the description never names the sibling or explicitly contrasts the two.

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

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

Usage is only implied: an agent can infer this is the follow-up to listing discussions, but the description gives no explicit when-to-use, prerequisites, or alternative (e.g., when to use get_forum_discussions versus this).

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 and openWorldHint=true. The description adds scope by saying it lists open discussions within a forum, but does not cover return format, pagination, auth, or rate limits. With annotations covering the safety profile, 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?

A single sentence with no filler, and the key scope constraint is front-loaded. The slash between 'temas / discusiones' is minor and does not hurt readability.

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

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

The tool is a simple read operation with one fully documented parameter and useful annotations. The description makes clear that it returns a list of open discussions; without an output schema, it could mention pagination or returned fields, but that is not critical here.

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 schema documents forum_id with an example format. The description only restates the forum scope and adds no syntax or format details 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?

States a specific verb (Obtiene) and resource (lista de temas / discusiones) scoped to a specific forum. It does not explicitly differentiate from sibling tools like get_discussion_posts or list_forums, 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?

Offers no explicit when-to-use guidance or alternatives. It does not say to use get_discussion_posts for post details or list_forums to find forums; usage is only implied by the phrase 'dentro de un foro específico'.

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 and openWorldHint=true, so the safety profile is covered by structured data. The description adds useful return-content context (weighted grades, percentages, qualitative teacher feedback) but says nothing about permissions, data freshness, or edge cases like a course with no grades.

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 resource and then enumerates returned content. No filler, though the closing enumeration is slightly padded.

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

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

With no output schema, the description carries the burden of describing return values and does so adequately (weighted grades, percentages, qualitative feedback). For a one-parameter read-only tool this is essentially complete; only ambiguity about empty/partial gradebooks remains.

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 field itself explains that course_id is the numeric ID of the subject. The description does not mention the parameter at all, so it adds nothing 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?

Specific verb ('Obtiene') plus a precise resource ('libro de calificaciones completo de una materia') and an enumeration of what it contains (weighted grades, percentages, qualitative feedback). It is distinguishable from siblings like get_assignment or list_courses, 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?

Usage is only implied: an agent infers it should be used when the full gradebook of a specific course is needed. There is no statement of when not to use it, no prerequisites, and no routing to sibling tools such as get_assignment or list_courses.

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 and openWorldHint=true, so the safety profile is covered. The description adds real context by noting deadline and submission status appear only 'cuando estén disponibles', warning that the field set is variable. It says nothing about pagination, ordering, or result volume.

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 verb and the scope, with the return-content caveat trailing correctly. No filler, though it is short enough that a touch more precision on scope would not have hurt.

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 listing with no output schema, the definition covers what it returns (deadlines, submission status) and what it scopes to (a single course). Missing only ordering/pagination expectations, which is minor at this complexity.

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

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

Schema coverage is 100% and the single parameter already documents that course_id is a numeric ID obtained via list_courses. The description adds no syntax, format, or validation detail 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 ('Lista') and resource ('tareas y actividades de una materia específica') plus the fields returned, which is far more than a restatement of the name. It implicitly distinguishes itself from get_assignment (single item) and submit_assignment (write), but 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?

Usage is only implied: the scope restriction to one 'materia específica' signals this is a per-course listing, and the schema notes course_id comes from list_courses. There is no explicit when-to-use/when-not or stated routing to get_assignment for detail.

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 and openWorldHint=true, so the safety profile is covered structurally. The description adds only the content scope (events, exam dates, submissions) and says nothing about ordering, result volume, or how the look-ahead window affects output.

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 tight sentence with the resource and its scope front-loaded; nothing redundant or padded. It could be marginally stronger by naming the look-ahead window already featured in the schema.

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

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

For a one-parameter, annotation-covered read tool with no output schema, the description is adequate: it names the calendar source and the kinds of items returned. Missing only minor details such as time horizon defaults, which the schema already supplies.

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 days_ahead parameter is fully documented, including its default of 30 and 10-year max. The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb ('Obtiene') and resource ('eventos, fechas de exámenes y entregas del calendario de Moodle'), so an agent knows it is a read of upcoming Moodle calendar items. It implicitly contrasts with calendar_add_event, but carries no explicit sibling differentiation.

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

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

The word 'próximos' implies this is for upcoming items rather than past or arbitrary ranges, which gives implied usage. However, it never states when to prefer this over calendar_add_event or other list tools, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by stating the enrollment scope and the returned fields, though it does not discuss authentication, pagination, or empty-result 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?

Two compact sentences, front-loaded with the operation and followed by the return values. Every sentence contributes useful information without redundancy.

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

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

For a parameterless read-only listing tool with annotations supplied and no output schema, the description is complete enough: it identifies the resource, the enrollment scope, and the returned fields. No critical invocation detail is missing.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain. The baseline for a parameterless tool is 4, and nothing in the description requires additional parameter guidance.

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: retrieving the list of courses/materias in which the student is enrolled at UTN Mendoza Campus Virtual. It also names the returned fields (ID, name, URL), making the operation clearly distinguishable from siblings such as list_assignments or get_grades.

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?

Provides clear context for use by specifying that it returns courses where the student is enrolled, which implicitly guides the agent to use it for enrolled-course listings. It does not name alternatives or exclusions, so it falls short of explicit when/when-not 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 and openWorldHint=true, so safety is covered. The description adds the scoping constraint (must be inside a course) and the taxonomy of forum types, but says nothing about result size, pagination, or what identifying fields come back.

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 verb and resource, with the examples earning their place by disambiguating 'foro' in an LMS context. No waste.

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 list tool with full schema description coverage and readOnlyHint annotations, the definition covers what is needed to call it. Return-shape details are the only real gap, and they are minor since no output schema exists but the resource is self-evident.

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 course_id parameter is fully documented in the schema itself. The description echoes the course scoping ('dentro de una materia') but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (listar) and resource (foros) scoped to a course, and the parenthetical examples (avisos, novedades, consultas) clarify what counts as a forum. It does not explicitly distinguish itself from get_forum_discussions or list_assignments, so the sibling differentiation is left to inference.

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: you call it to see the forums within a given course. There is no statement of when to prefer get_forum_discussions or get_discussion_posts instead, nor any prerequisites (enrollment, permissions) for the call.

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 and openWorldHint=true, so the safety profile is covered. The description adds the shape of the result (participants with roles and groups), which is valuable since there is no output schema, but it says nothing about permissions, enrollment requirements, or result size.

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

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

A single well-formed sentence with zero filler, front-loading the action and resource. It is appropriately sized, though it could have used the remaining space to add one routing hint.

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 tool with full schema coverage and annotations, the description covers what is listed and the returned content fields. Missing only permission/visibility caveats, which are minor here.

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%, including the role enum with its 'all' default, so the schema carries the parameter semantics. The description only alludes to the course scope via 'de una materia' and adds no filtering detail or ID format guidance 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 and resource ('Lista los participantes de una materia') and specifies the returned content (students and teachers with roles and assigned groups), which separates it from siblings like list_courses or get_grades. It does not explicitly name a sibling it is NOT, so it stops short of a 5.

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

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

Usage is implied by the resource name: use it when you need the roster of a course. There is no explicit when-to-use, no prerequisites (e.g. must be enrolled or have access), and no mention of alternatives such as whoami for the current user's own identity.

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 and openWorldHint=true, so the safety profile is known. The description usefully adds what kinds of items are returned and that they are grouped by topic/section, but says nothing about pagination, ordering, or empty-result 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?

One front-loaded sentence with no filler that enumerates the resource types and their organization. Efficient, though it packs a list rather than leading with the core action.

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, single-parameter listing tool with full schema coverage and annotations covering safety, the description is essentially complete. The only minor gap is return shape/ordering, which is not strictly required since no output schema exists but would help.

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 a single parameter and 100% schema description coverage (including the example '126' and the pointer to list_courses), the schema carries the semantics. The description adds no parameter detail beyond the course scoping implied by 'dentro de una materia'.

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?

It states a specific verb (listar) plus resource (materiales de estudio, enlaces, páginas, archivos) and the organizing dimension (tema/sección dentro de una materia). Very clear what it returns, though it does not explicitly differentiate itself from siblings like read_file or list_assignments.

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 'dentro de una materia', and the course_id schema text routes the agent to list_courses first. However, the description itself gives no explicit when-to-use/when-not or alternative tool 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 declare readOnlyHint and openWorldHint, so the safety profile is already covered. The description adds that it returns structured content, internal activities, and a parent link, which helps the agent understand output behavior without an output schema. It omits auth, rate-limit, or error behavior, so it is 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?

A single front-loaded sentence covers scope, examples, and return behavior with no wasted boilerplate. It remains readable despite its length.

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 navigation tool with no output schema, the description is nearly complete: it explains input scope, what is returned, and parent-link navigation. It could mention prerequisites or how nested activities are handled, but the core is covered.

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 schema thoroughly documents id_or_url and section_id. The description enumerates element types that map to id_or_url but adds no new parameter semantics beyond the schema, 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?

It states a specific action ('Entra a...') and enumerates the Moodle resource types it opens, so the purpose is clear. It does not explicitly name sibling tools like get_assignment or list_courses, so sibling differentiation is only implicit through 'navegación jerárquica unificada'.

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 opening and navigating any Moodle element by ID/URL, and mentions the parent link for navigation. It gives no explicit when-to-use versus list_* or get_* alternatives, nor when not to use 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuinely non-obvious behavior: OCR never downloads models and is disabled by default, and PDFs support per-page/fragment reads. It stops short of describing output shape (page vs fragment, what happens on truncation), which would have made this 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 that front-load the capability before the constraints, with no filler. It is dense but every clause carries information an agent needs; only the format enumeration slightly duplicates the schema enum.

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 six parameters, no output schema and 100% schema coverage, the description covers the format matrix and the OCR constraint well enough to call the tool correctly. What is missing is the practical consequence of truncation (which offset/page_size combination to use on a retry) and any statement about what the returned text looks like.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, which sets the baseline at 3. The description restates page/fragment-offset/OCR semantics and adds the format-implies-tables nuance, but contributes no syntax or interaction detail (e.g. how offset and page_size interact) 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?

Uses a specific verb pair ('Descarga y extrae texto/tablas') plus an enumerated list of supported formats, which is far more precise than the generic name read_file would suggest. It does not name or distinguish itself from likely siblings like open or list_resources, so an agent must infer the boundary 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?

The description implies the usage domain (download and extract document content) and gives one conditional constraint (OCR only with local Tesseract models, off by default). It contains no explicit when-to-use/when-not guidance and gives no routing hint relative to open, list_resources, or get_assignment, all of which could plausibly return document 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?

Annotations only say destructive=true and idempotent=false; the description adds substantially more: a two-phase human-in-the-loop gate, an external approval minted out-of-band via `npm run approve:assignment -- <id>`, single-use semantics, approval expiry, and an execution kill-switch by local policy. These are exactly the operational constraints an agent could not derive from the annotations.

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

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

Three dense sentences, front-loaded with the staged model, then the human approval step, then the policy gate. Each sentence carries required information. Minor friction from heavy clause stacking ('esa aprobación exacta, de un uso y con vencimiento') and from not naming the resource explicitly.

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, open-world write with 7 parameters and no output schema, the description covers the safety-critical path thoroughly: gating, approval provenance, single use, expiry, and disabled-by-default. The remaining gap is return behavior, since there is no output schema and the description never says what prepare hands back (implicitly an <id> the human must quote) or what execute reports on success/failure.

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 the baseline is 3, and the schema already documents stage, approval_id, confirm and submission_action. The description still adds meaning by characterizing approval_id as exact-match, single-use and time-limited, a constraint absent from the parameter's own description and decisive for how the agent should treat the ID. It says nothing about assignment_id, text_content or attachment_paths, but the schema covers those.

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 both stages and their concrete actions ('prepare inspecciona el formulario y crea una operación local pendiente'; 'execute solo usa esa aprobación'), so an agent knows this is the scripted submission flow rather than a plain write. However, it never states plainly that the tool submits assignment content/files to Moodle, and it makes no explicit contrast with mutating siblings like submit_choice or forum_reply.

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 routing conditions: use prepare to inspect the form and create a pending operation, use execute only with an approval produced by the human-run CLI command. It also states a hard when-not: 'La ejecución está deshabilitada por política local hasta habilitación explícita.' Nothing about stage selection is left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces rather than contradicts them: it explains WHY no write occurs (submission to Campus disabled pending independent human approval) and pre-empts the trap of passing confirm:true. It stops short of describing validation failure behavior or what the preview returns, 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, zero waste, with the key constraint (no real submission, confirm:true cannot override) placed prominently up front. 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?

For a read-only preview tool with full schema coverage and no output schema, the description covers the essentials, including the surprising no-op semantics of confirm. A brief note on what the preview reports (valid/invalid, already-voted) 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 the schema already explains confirm, choice_id and option_id in the same terms. The description's mention that confirm:true does not enable the write is useful emphasis but repeats the schema's own confirm description rather than adding new semantics.

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

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

States a concrete verb pair (valida y previsualiza) and a concrete resource (una opción de mod_choice), so an agent knows this is a validation/preview operation rather than a real submission. It does not name the sibling get_choice as the read alternative, so sibling differentiation rests on inference. Clear but not maximally distinguishing.

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: it is for checking an option before any real submission, and the second sentence warns that confirm:true will not make the write happen. However, it never says when to prefer get_choice or how this relates to actually completing the choice, so the agent must infer the workflow position.

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 and openWorldHint=true, so the safety profile is covered. The description adds value by naming the exact fields returned, but says nothing about authentication/session requirements, failure modes when no user is logged in, or timezone format — context that matters for a session-scoped lookup.

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 enumerated field list earns its place because there is no output schema. Slightly long as one sentence but nothing is wasted.

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

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

With no parameters and no output schema, the description carries the burden of describing the return payload and does so by listing all four fields, which is sufficient for an agent to decide to call it. Missing only session/auth caveats and error 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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly conveys that no arguments are needed by framing the result as the implicitly-logged-in student.

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

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

States a specific verb ('Obtiene') and resource (the logged-in student's profile on Campus Virtual UTN Mendoza) and enumerates the returned fields (name, email, enrolled courses, timezone). No sibling tool overlaps with this 'current user' capability, so differentiation is implicitly clear, though it is never stated 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 can infer this is the tool to call when it needs identity/context about the current session, and that other tools (list_courses, get_grades) are the resource-specific alternatives. There is no explicit 'use this when…' guidance or statement about prerequisites such as an active session.

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