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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing that `archivos` is a final replacing list, that omission preserves existing values, that submission is generally irreversible once sent, that a declaration may need acceptance, and that the user must confirm beforehand. This matches and enriches the destructive/irreversible semantics declared in 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?

Front-loads the core action followed by prerequisites, replacement semantics, and the confirmation requirement — every paragraph carries distinct information. It is somewhat long and drifts into fluent narrative, but no sentence is 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 destructive write tool with no output schema it covers prerequisites, irreversibility, replacement semantics, and the confirmation protocol. Return value is only gestured at ('Devuelve cómo quedó la entrega'), which is the one remaining gap, though acceptable given the complexity covered elsewhere.

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 per-parameter meanings are already documented, but the description adds cross-parameter semantics the schema cannot express: empty `archivos` removes all files, existing files must be re-listed by `url` to be preserved, and omitting `texto`/`archivos` leaves prior values. That is meaningful value 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 — submitting an assignment in the virtual classroom — and explains that it can upload files, write inline text, or both depending on what the task accepts. It is clearly distinguishable from siblings like aula_open (inspection) and aula_read_file.

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

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

Explicitly requires calling aula_open first to read `entrega` (accepted types, size, puedeEditar, existing uploads) before submitting. It also spells out the draft vs. non-draft branch, the `enviar: false` alternative, and the human-confirmation step, so the agent knows exactly when and how to invoke 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?

Beyond the annotations (which only declare the write/non-destructive/non-idempotent profile), the description discloses two real behavioral traits: the event's visibility is private to the user, and creating it triggers notifications according to the user's notification settings. It does not cover failure modes or whether duplicates are permitted.

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 short sentences, front-loaded with the core action and visibility scope, followed by side-effect and format notes. Every sentence carries information; nothing is repeated verbatim across sentences.

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 4-parameter, non-destructive create tool with annotations and no output schema, the description covers purpose, visibility, notification side effect and date format. Minor gaps remain around return value and duplicate handling, but nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already carries titles, formats and examples for all four parameters. The description reinforces the timezone requirement and localizes the offset for Argentina (-03:00), which adds modest value but largely restates the 'inicio' 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 and resource ('Agrega un evento personal al calendario del aula virtual') and adds a scope qualifier ('que solo ve el usuario') that separates it from shared/public posting tools like the forum siblings. It never names a sibling, so differentiation is by resource type rather than explicit contrast.

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

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

Concrete use cases are given ('un recordatorio de un parcial o una entrega'), which tells the agent the intended context. There is no when-not guidance or named alternative, so it stops short of full routing instruction.

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

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

Beyond the annotations it discloses the key mutation semantics: the call replaces the previous answer rather than appending, an empty list deletes the answer, `deshabilitada` options are already full, and some choices are locked after the first submission. This aligns with and enriches destructiveHint=true and idempotentHint=true rather than merely restating them.

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 short paragraphs that are front-loaded with the core action, then preconditions, then the confirmation rule. Every sentence carries distinct information with no repetition of the schema or annotations.

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

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

No output schema exists, yet the description covers the return ("Devuelve cómo quedó la elección"), the source of the option ids, the irreversibility risk, and the required user-confirmation step. Nothing an agent needs in order to call it safely is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the baseline is 3. The description still adds real meaning: `opciones` is a full-replacement set (not incremental), an empty array erases the answer, multiple ids are only valid when the activity permits, and `direccion` comes from the module opened via aula_open.

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

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

The description states a concrete verb and resource ("Responde una elección") and distinguishes its two modes: choice (quick polls) and choicegroup (signing up for a group/commission), each with a concrete example. No sibling tool overlaps this resource, but the description never names a sibling to contrast with, so it stops short of the top score.

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?

"Las opciones salen de `eleccion` al abrir el módulo con aula_open" supplies the prerequisite and the sibling that must run first, and the confirmation instruction gives a hard procedural rule before calling. It falls short of a 5 because it warns that many choices cannot be changed (`puedeCambiar: false`) without stating whether the call should then be skipped or simply flagged to the user.

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

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

Annotations already declare `destructiveHint=true`, but the description adds essential context beyond them: deletion cannot be undone, it is gated on `borrar` in `acciones`, and deleting the first post removes the entire discussion. It also requires showing the user exactly what will happen and waiting for confirmation.

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

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

The description is tightly written: destructive action and irreversibility are front-loaded, followed by the permission gate, cascade risk, and confirmation instruction. No sentence is filler or 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?

For a destructive mutation with no output schema, the description covers the key operational facts: irreversibility, permission gating, cascading deletion of the whole discussion, and required user confirmation. Nothing critical to safe 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%, and both `id` and `direccion` are fully documented with examples in the schema. The description adds only indirect scoping through 'publicación propia' and does not define parameter formats beyond what the schema already provides, 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?

The description gives a specific verb ('Borra') and resource ('una publicación propia de un foro'), with the ownership scope making the operation distinct from creating or editing posts. The cascade note further clarifies exactly what kind of deletion this is.

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 states a clear precondition ('Solo se puede si tiene "borrar" en `acciones`') and mandates a confirmation workflow before calling, which tells the agent when the tool is allowed to be used. It does not explicitly compare with alternatives such as `aula_forum_edit_post`, 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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new behavioral context: the prior message is fully replaced (not merged), the editability window is time-limited and discoverable via `acciones`, and a user confirmation is required first. It does not describe what an error looks like when the window has expired, but the mutation semantics are well disclosed.

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 no filler: capability and replacement scope first, then the precondition and the confirmation requirement. Every clause is actionable.

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 mutation with full schema coverage and clear annotations, the description covers what changes, when it is permitted, and that confirmation is required — enough to call it correctly. Only the failure mode after the edit window lapses and any alternative path 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?

Schema description coverage is 100%, so all four parameters (id, asunto, mensaje, direccion) are already documented with examples. The description only echoes the schema's replacement semantics for `mensaje` and adds no syntax, format, or validation detail beyond it. Baseline 3 applies when the schema carries the load.

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 ('Edita una publicación propia de un foro') plus the key scope detail that it replaces the whole message, which implicitly separates it from aula_forum_post and aula_forum_delete_post. It never names those siblings explicitly, so an agent must infer the boundary rather than read it.

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 a concrete precondition ('Solo se puede si la publicación tiene "editar" en `acciones`') and explains why it may fail (Moodle only allows edits for a limited time). It also mandates a confirm-with-user step before calling. It stops short of naming an alternative action (e.g. delete-and-repost) when the edit window has closed.

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 it is a non-idempotent, non-destructive, open-world write; the description adds the crucial consequence that the post is visible to teachers and classmates and that many receive it by email — an irreversible public side effect not conveyed by any annotation. It also surfaces the API-level preconditions and a mandatory human confirmation step.

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 short paragraphs, front-loaded with the core action and mode split, then preconditions, then the confirmation requirement. Every sentence carries operational information; nothing is 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?

For a write tool with no output schema, the description covers the mode selection, required fields per mode, API-level gating fields, audience/notification consequences, and the confirmation protocol. An agent has everything needed to call it correctly and 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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: `direccion` is a mode switch (forum address vs discussion address) and, when `respuestaA` is omitted, the reply targets the first post — a default the schema does not document. The rest (asunto required for new threads, respuestaA only when replying) duplicates the schema.

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

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

States a specific verb and resource ("Publica en un foro del aula virtual") and then splits it into two clearly-defined modes: opening a new thread from a forum address vs replying within a discussion. The behavior is unambiguous, though it never names the sibling tools (aula_forum_edit_post, aula_forum_delete_post) to explicitly rule them out.

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

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

Explicitly says which mode applies to which `direccion` type, what is required in each case (`asunto` for new threads), and gives preconditions to verify first: `puedeAbrirHilo` before opening a thread and the presence of "responder" in `acciones` before replying. It also mandates showing the user the intended action and waiting for confirmation, which is a concrete when-to-call rule.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description only adds that the data belongs to the currently authenticated user and the Moodle site, implying a session/auth dependency without stating failure modes or what happens when unauthenticated.

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 compact sentence with no filler. It is front-loaded, though it lacks a leading action verb that would make the intent land faster.

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 parameters, the description is the only source of information about the return value, yet it never says which fields (name, email, legajo, site name, etc.) come back. Adequate to identify the tool, insufficient to predict its response.

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

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

Zero parameters and 100% schema coverage, so the baseline is 4; there is nothing parameter-wise the description needs to 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 description names the resource (the logged-in user's data plus Moodle site data from the UTN FRBA virtual classroom) but supplies no verb such as 'retrieve'/'get', and 'Datos' is generic about what is actually returned. It is distinguishable from the action-oriented siblings (forum_post, assign_submit) as a read of identity/site context, but only loosely.

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 the other aula_* tools, and no prerequisites or follow-up guidance. An agent must infer that it is an identity/bootstrap call to be used before acting on courses or forums.

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=false, so the safety profile is covered. The description adds valuable output context absent from any output schema: each course includes a `direccion` field intended for aula_open. It doesn't mention auth/session requirements or ordering, but adds real 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?

Two short sentences, zero waste: the first states what is listed, the second delivers the workflow-critical detail (the `direccion` handoff) immediately. Front-loaded and easy to scan.

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 entry-point tool with no output schema, the description covers purpose, user scoping, the returned field that matters, and the next call. Safety is already covered by annotations, so nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input filtering is needed and instead explains the shape of each returned item, which is the relevant semantic detail here.

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 cursos... en los que está inscripto el usuario') and immediately positions itself in the workflow as 'el punto de entrada', distinguishing it from aula_open by naming the handoff via `direccion`. An agent can identify its role without reading 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?

Explicitly frames the tool as the entry point and names the follow-up action (pass `direccion` to aula_open), which tells the agent when to call it first. It does not state exclusions or what to do if the list is empty, but the sequencing guidance is clear.

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=false, but with no output schema the description must carry the return shape, and it does: per-module extras (entrega, eleccion, puedeAbrirHilo, acciones), `padre`/`direccion` links, and file `url` semantics including that it requires the user's own session. It does not discuss failure modes for an invalid or stale address, which is the main remaining gap.

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-loaded with the core behavior, then progressively adds module-specific detail and navigation guidance — each paragraph earns its place. Slightly long, with a little redundancy around the `direccion`/`padre` navigation idea repeated across paragraphs.

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?

Complete for a navigation/read tool: entry point, traversal mechanics, per-type return contents, the ids required by write tools, and delegation to aula_read_file and aula_list_courses. Nothing an agent needs to call it correctly is missing, and the only omission (error behavior on bad addresses) is minor.

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; the description still adds genuine meaning by saying the address must come from a previous response and that it should not be assembled by hand, plus how `pagina` interacts with `hayMasDiscusiones`. It adds navigation semantics beyond the schema's format examples.

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 and resource ('Entra a una dirección del aula virtual') and immediately enumerates what each address type returns (curso, módulo, foro, discusión), which separates it from siblings like aula_read_file and aula_list_courses. An agent can pick this tool without opening the schema.

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

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

Explicit entry point ('usar aula_list_courses o la dirección "/"'), explicit navigation rule (pass back `direccion` or `padre`), and explicit handoffs to alternatives: forum index instead of full messages, aula_read_file for archivos/cronograma. Covers when to use this vs. siblings rather than leaving it 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?

Annotations already declare readOnly and closed-world, and the description adds real context beyond that: pagination limits (only what fits in one response), scanned PDFs returned as page images, and error behavior for unsupported formats. No permissions or rate-limit details, but the behavior profile is solid.

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 short paragraphs, each with a distinct job (what it reads, how pagination works, what fails). Front-loaded with capabilities and zero 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 two-parameter read tool with no output schema, the description covers supported formats, partial-return behavior, continuation mechanism, and failure mode. An agent has everything needed to call it and interpret 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 coverage is 100%, so baseline is 3, but the description adds meaning: it explains why `desde` exists (skipping to a part) and that `siguiente` points to the next chunk, which clarifies the pagination semantics the schema alone 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?

States a specific verb (read a file from the virtual classroom) and enumerates the supported formats (PDF, docx, pptx, xlsx, images, text). It also implicitly differentiates from the sibling aula_open by noting the `url` comes from that tool's output.

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 operational guidance: files come back in parts, `siguiente` tells where to continue, and `desde` lets you jump. Unsupported formats are covered with the fallback behavior (error with download URL). It lacks an explicit statement of when to prefer a sibling, but the context is clear.

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 a non-read-only, non-destructive, non-idempotent, open-world write, and the description adds real context: the send must be previewed to the user and confirmed first, and the response returns the recipient's name. The anti-hallucination warning about usuarioId is genuinely behavioral rather than restating schema. It stops short of describing error or rate-limit 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 short paragraphs, both front-loaded: the action and audience first, then the id-provenance rule, then the confirmation requirement. Every sentence carries operational weight with no repetition of schema fields.

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

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

For a two-parameter, no-output-schema write tool, the description covers what it does, how to obtain the non-obvious id, what the response returns, and the required human-in-the-loop step. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns above that by explaining where usuarioId comes from (autorId via aula_open) and explicitly forbidding guessing it from a name — provenance that the schema does not state. mensaje's plain-text nature is already covered by the schema.

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

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

Names a specific verb and resource ("Manda un mensaje privado por la mensajería del aula virtual") and scopes the audience ("a otro usuario, docente o compañero"). That clearly separates it from sibling write tools like aula_forum_post, which publishes to a thread rather than a private inbox.

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

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

Gives an explicit precondition for obtaining the required id ("sale del `autorId` de un foro o una discusión abiertos con aula_open") and routes the agent to aula_open first. It also mandates a confirmation step before sending. It does not explicitly say when to prefer aula_forum_post over a private message, so no exclusions are stated.

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