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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the write-to-disk profile is partially covered. The description adds that the target is a 'protected downloads folder', useful destination context, but says nothing about overwrite behavior, required authentication, or whether an existing file is replaced.

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. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

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 5-parameter download tool with no output schema and zero schema description coverage, the description is far too thin. It omits where the file lands, how the four required IDs are obtained, and what happens on name collisions.

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% across 5 parameters (4 required, three with ID patterns), so the description carries the full burden and adds almost nothing. It does not explain the courseId/contentId/attachmentId relationship, what filename is used for, or how outputDir interacts with the 'protected downloads folder'.

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+scope: downloads a specific attachment into the protected downloads folder. An agent can distinguish it from list_attachments or download_course_materials, though it never names which sibling handles the broader/URL-based cases.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as download_file_url or download_course_materials, which are close siblings in the same tool family. The agent must infer the selection criteria from the name alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the write profile is covered. The description adds genuinely useful context beyond that: only accessible content is traversed and failures/omissions are recorded in manifest.json. It omits auth/permission requirements, rate limits, and what happens on partial failure beyond the manifest.

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, and the primary action is front-loaded ahead of the exclusion. It is arguably too terse for a bulk operation with side effects, which keeps it from a 5.

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

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

For a side-effecting bulk downloader with no output schema, the description covers the main flow, the manifest artifact, and the submissions exclusion. It leaves gaps on permissions, the courseId format, and behavior on partial/interrupted runs, so an agent knows roughly what happens but not all the constraints.

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 description mentions no parameter at all. With schema coverage at only 50% and courseId carrying an unexplained pattern (^_\d+_\d+$) and no description, the description needed to compensate and does not; only outputDir is documented, and that is in the schema, not the 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 specific verbs and resources: traverses accessible contents/activities, downloads materials, and writes a manifest.json. This is clearly a bulk-download tool, distinct from single-file siblings like blackboard_download_attachment and from list-only tools like blackboard_list_downloaded_materials. It stops short of naming a sibling, so it lands at 4 rather than 5.

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

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

The clause 'No hace entregas' gives one explicit exclusion, and 'contenidos y actividades accesibles' implies the scope of use. However, it never says when to prefer this over blackboard_download_attachment, blackboard_download_file_url, or blackboard_list_downloaded_materials, so the alternative-routing 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the agent knows this is a non-idempotent, network-touching operation that writes something. The description adds nothing beyond that: no statement of where the file lands, whether it overwrites, or what auth/session is required, which matters for a tool that saves a file.

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 very short sentence is technically efficient, but here brevity reflects under-specification rather than conciseness. There is no front-loaded detail about inputs, destination, or result that an agent needs before invoking it.

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, 0% parameter coverage, and only partially compensating annotations, the definition leaves the critical question of where and how the file is written unanswered. For a tool whose whole outcome is a saved file, this is incomplete.

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 all three parameters (url, filename, outputDir). The description only echoes 'URL', leaving filename and especially outputDir (the destination directory) completely undefined in both schema and prose, so an agent must guess the semantics of the save target.

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 ('Descarga') and a specific resource type (a bbcswebdav URL from Blackboard UP), so the basic action is identifiable. However, it never distinguishes itself from close siblings like blackboard_download_attachment or blackboard_download_course_materials, so an agent cannot tell which download tool applies without inspecting schemas.

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 gives no when-to-use guidance and names no alternatives, even though several sibling tools also download Blackboard content. An agent has no signal for choosing this URL-based downloader over the attachment or course-material downloaders.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true. The description adds real context beyond them: the output is a private CSV, missing records are left empty, and the export scope is limited to the caller's own account. It does not say whether an existing file is overwritten, 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?

Two compact, front-loaded sentences that lead with the action and the artifact produced, then add the scope caveat. No filler, though the second sentence's value is modest.

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/export tool with 0% schema coverage, no output schema and three unexplained parameters (including a patterned required id), the description leaves too much unstated. It conveys what is produced and its scope, but not the courseId format, the meaning of outputDir or allowPartial, or overwrite behavior.

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

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

Schema description coverage is 0% and the description explains none of the three parameters. The required courseId carries a cryptic pattern '^_\d+_\d+$' that is undocumented in both schema and description, and outputDir / allowPartial are completely unexplained, so the description fails to 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 states a specific verb and resource: 'Guarda CSV privado de tu asistencia' (saves a private CSV of your attendance), which tells the agent it is a file-export operation rather than a read. It implicitly distinguishes itself from the sibling blackboard_get_my_attendance by emphasizing the CSV export, but it never names that sibling or any 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?

Usage is implied by 'Guarda CSV' (use this when you want a saved file rather than an inline read) and there is an explicit exclusion: 'No exporta otras cuentas' (does not export other accounts). However there is no explicit statement of when to prefer this over blackboard_get_my_attendance or any other attendance sibling.

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 a non-read-only, non-idempotent, open-world write. The description adds real behavioral context beyond that: it writes to the downloads root, does not sync calendars, does not expand recurrences, and rejects failed sources unless allowPartial=true. These are meaningful operating constraints an agent cannot derive from the annotations alone.

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, front-loaded with the core action and followed by the constraints. No filler; each clause carries a distinct behavioral fact.

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 an export tool with no output schema and sparse parameter coverage, the description covers the essential write semantics and partial-failure behavior, but omits file naming, return value, and the date-range parameters that drive the export. Adequate but not complete.

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

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

Schema description coverage is only 20%, so the description must compensate. It clarifies allowPartial (the partial-failure escape hatch) and implicitly the outputDir destination ('raíz de descargas'), but says nothing about since, until, or the courseId format, leaving three of five parameters 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?

States a specific verb and resource: saving a .ics copy of the dates returned by the agenda into the downloads root. This distinguishes it from the read-only sibling blackboard_get_course_agenda, though it does not explicitly name that sibling or the multi-course export variant.

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 'export' semantics, and the description notes the allowPartial escape hatch for failed sources. However, it never states when to choose this over blackboard_get_course_agenda or blackboard_export_multi_course_agenda, leaving the routing 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 declare readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false, covering the safety profile. The description adds valuable data-handling semantics: preserves zeros, missing cells, separate scale fields, and explicitly does not compute final average. It does not mention overwrite or file naming behavior, but goes 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 sentences, front-loaded with the core action, then data-handling caveats. Every sentence earns its place; 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?

For a 3-parameter export tool with no output schema and rich annotations, the description covers what it does and the output format, but omits parameter guidance and when-to-use context. Adequate but gaps remain.

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 provides a description only for outputDir (33% coverage); courseId and allowPartial are undocumented in both schema and description. The description mentions 'cuenta autenticada' but does not explain courseId pattern or allowPartial behavior, failing to compensate for low coverage.

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

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

States a specific verb ('Guarda') and resource ('notas publicadas') with output format ('CSV local'). Distinguishes from calculation tools by 'no calcula promedio final', but does not explicitly contrast with sibling tools like blackboard_export_multi_course_grades or blackboard_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?

No explicit when-to-use, prerequisites, or alternative tools are mentioned. Only an implicit context that it exports published grades. Lacks guidance on when to choose this over get_grades or multi-course export.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false, so the agent knows this writes something into an open world. The description adds that the output is a *private* JSON file with structure and sources, which is real value beyond the annotations, but says nothing about where it is written, whether it overwrites, or the cost of large exports.

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 the core action front-loaded; no filler. The semicolon-joined caveat is slightly compressed but still readable.

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?

A write tool with 5 undocumented parameters, no output schema, and no explanation of the produced artifact's location or shape. Given the complexity, the description is too thin for an agent to invoke it correctly without guessing at parameters.

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% across 5 parameters, so the description carries the full burden and largely fails it: it only alludes to allowPartial ('sin allowPartial') and says nothing about courseId format, maxDepth, maxItems, or outputDir.

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: 'Guarda JSON privado con estructura y fuentes de un curso' (saves a private JSON with the course's structure and sources). This distinguishes it from read-only siblings like blackboard_get_course_outline and places it among the blackboard_export_* family, though it never names a 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 clause 'evita exportar consultas incompletas sin allowPartial' implies the usage condition (use allowPartial when the query would otherwise be incomplete), which is useful implied guidance. But there is no explicit when-to-use/when-not framing versus blackboard_get_course_outline or the other export tools.

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

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

Annotations already flag a non-read-only, non-idempotent, open-world write. The description adds real context beyond them: it writes an ICS file to downloads/exports and explicitly does not sync calendars, which preempts a common misuse. It stops short of saying whether existing files are overwritten.

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

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

Two tight clauses, front-loaded with the export action and followed by the two constraints. No padding, though the phrase is dense and slightly telegraphic.

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 5-parameter write tool with no output schema and zero schema descriptions, the description covers the key behavioral questions (side effect location, no sync, partial flag) but leaves the required date-range parameters and outputDir fallback unexplained.

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 carry the load. It conveys the course-count bound (1-10), the destination directory (downloads/exports, implying outputDir), and the meaning of allowPartial, but says nothing about the since/until semantics or the required '_N_M' course ID shape already encoded in the schema pattern.

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+resource: exporting an ICS copy of dates for 1-10 courses, with per-section identifiers. That is enough to separate it from the single-course blackboard_export_course_agenda, though it never names siblings explicitly.

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

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

'No sincroniza calendarios' rules out a plausible alternative interpretation (calendar sync), and 'parcial solo con allowPartial' gives the condition for partial output. It doesn't tell the agent when to prefer this over export_course_agenda for one course, so guidance is implied rather than complete.

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 this is a non-read-only, open-world, non-idempotent, non-destructive write. The description adds genuinely useful behavior beyond that: the output is a private CSV, missing grades and zeros are preserved, and no averages or scales are computed — non-obvious data-handling semantics. It stops short of covering file destination, overwrite behavior, or permissions.

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 primary action, and every clause carries information (what is produced, what is preserved, what is not computed). It is terse enough that it borders on under-specification rather than 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?

A file-writing tool with no output schema, no parameter documentation, and three parameters where outputDir and allowPartial are unexplained in both schema and description. An agent cannot determine where the CSV is written or how partial results behave from this definition alone.

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 three parameters. The description only loosely maps to courseIds via 'cursos elegidos' and says nothing about outputDir (where the CSV lands) or allowPartial (how partial failures are handled), so it fails to compensate for the schema 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?

States a specific verb and resource: saving a CSV of grades for the chosen courses. The plural 'cursos elegidos' implicitly distinguishes it from the single-course export_course_grades and the read-only gradebook getters, though it never names those siblings explicitly.

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

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

Usage is implied by 'cursos elegidos' (multiple selected courses), which points at the multi-course export case, but there is no explicit when-to-use statement, no exclusion, and no reference to export_course_grades or get_multi_course_gradebook as 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 cover the safety profile (write, non-idempotent, non-destructive, open-world), and the description adds real value beyond them: the output is a private Markdown summary, it does not download the underlying document, and it does not guarantee the current syllabus. These are non-obvious behavioral caveats. It still omits what the write does to existing files or where output lands.

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 the core action front-loaded and the caveats following. No filler, though the negative clauses could be structured more crisply.

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?

A five-parameter write tool with no output schema and no annotation detail on file handling needs more: where the Markdown is written, what allowPartial does, and the courseId format are all missing. The description is too thin for the tool's 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 description coverage is 0%, so the description must carry the parameter burden, but it only loosely gestures at dates and syllabi. courseId format, outputDir, and allowPartial are entirely unexplained in both schema and description, leaving half the parameters opaque.

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) and resource (resumen Markdown de fechas y posibles sílabos), and explicitly clarifies it is not a downloader, which distinguishes it from download/find-syllabus siblings. It is slightly vague about what 'fechas' are summarized, keeping it from a 5.

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

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

The caveat 'No descarga el documento' implicitly signals this is not a replacement for download tools, and 'no garantiza que sea el sílabo vigente' warns of output reliability. However, no sibling is named and no explicit when-to-use condition is given, so usage 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, matching the described write behavior ('Guarda'). The description adds a useful trait — the output is a 'privado' (private) CSV — but says nothing about where the file lands, overwrite behavior, or auth requirements.

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

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

A single, front-loaded sentence with no wasted words. It is efficient, though its brevity is partly the reason other dimensions are under-served.

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 file-export tool with no output schema and zero parameter documentation, the description is too thin — it omits output location, partial-export behavior, and prerequisites. An agent could guess the basic intent but lacks what it needs to call it correctly.

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% across four parameters, so the description carries the full burden, yet it explains none of them. It implies columnId maps to an 'actividad' (activity), but outputDir and allowPartial are entirely undocumented in both the schema and the 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 (Guarda/Saves) and resource (CSV of submission receipts for an activity), and even clarifies scope with 'incluyendo ausencia de comprobante'. However, it never distinguishes itself from the close sibling blackboard_get_submission_receipts, so the agent must infer the export-vs-fetch difference.

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 mention of when to prefer this over blackboard_get_submission_receipts, and no explanation of when optional parameters like outputDir or allowPartial matter. The scope note about including missing receipts is the only hint about usage.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that REST attachments are included and that candidates with IDs are returned, which is useful but modest context beyond 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?

Two tight clauses, front-loaded with the core action and followed by the return behavior. Little waste, though the parenthetical 'incluye adjuntos REST' is somewhat cryptic.

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, idempotent search tool with no output schema, the description does mention the return shape (candidates with IDs), but it omits how it relates to sibling search tools and the title/text/filename wording has no matching parameter, leaving a gap an agent cannot resolve.

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 75% (maxDepth/maxItems/maxResults documented, courseId not), so the baseline is 3. The description names search dimensions (title/text/filename) that do not actually correspond to any schema parameter, so it neither explains the numeric limits nor the required courseId.

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 ('Localiza') and resource ('sílabos') with the search dimensions (título, texto, nombre de archivo) and notes it covers REST attachments. An agent can tell it is a syllabus-finding tool, though it never contrasts itself with the other search tools among the 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?

Implies the workflow – find candidates, then use the returned IDs to verify the section – but gives no explicit when-to-use, prerequisites, or alternatives such as blackboard_search_contents. Usage must be inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only a hint that the announcement must be accessible and that text and dates are returned; it says nothing about permission failures or what happens when the announcement is not accessible.

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 short sentence with no padding, which is good, but it is under-specified rather than genuinely concise — it omits the details that would make the sentence earn 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?

With no output schema, two undocumented required parameters, and no guidance on the ID formats or access constraints, the description leaves significant gaps for an agent to fill by trial and error. A read-by-ID tool needs at least the identifier contract spelled out.

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 carries the full burden for two required parameters. 'De la sección indicada' loosely maps to courseId and 'un anuncio' to announcementId, but neither the ID format (the ^_\d+_\d+$ pattern) nor any required relationship between them is explained.

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

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

The description identifies the resource (an announcement) and the returned content (text and dates), so the purpose is inferable, but the verb is implicit and it never distinguishes this single-item fetch from siblings like blackboard_list_announcements or blackboard_search_announcements. It is adequate but not specific enough for an agent to route confidently.

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

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

There is no statement of when to use this tool versus the list or search announcement variants, and no prerequisites beyond the vague qualifier 'accesible'. The agent must infer that this is the by-ID detail fetch while the siblings handle listing and searching.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety and idempotency profile is clear. The description adds that it gathers various components and reports incomplete queries, which is useful behavioral context beyond annotations. However, it doesn't elaborate on what 'informa consultas incompletas' means operationally or any rate limits or auth requirements.

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

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

The description is a single, dense sentence that covers multiple aspects without unnecessary words. It front-loads the main purpose. However, the Spanish phrasing is somewhat cryptic and could be clearer for an international audience.

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

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

For a tool with no output schema and 0% schema description coverage, the description is too terse. It doesn't explain what the returned metadata includes, how attempts are accessed, or what 'informa consultas incompletas' entails. Given the complexity of the data being aggregated and the lack of structured documentation, this is inadequate.

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 schema description coverage at 0% for both parameters (courseId and columnId), the description should compensate but provides no information about parameter meaning, format, or expected values beyond what's inferable from names. The pattern constraint is in the schema but not explained. This leaves significant gaps for an agent to invoke correctly.

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 it aggregates metadata, content instructions, attachments, and accessible attempts for an activity, which is a specific verb+resource combination. However, it doesn't distinguish this tool from siblings like blackboard_get_content or blackboard_list_assignments, and the term 'actividad' is somewhat generic for what appears to be an assignment details tool based on the name.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The description implies it's for getting assignment details, but with many sibling tools related to assignments and content, it fails to clarify the selection context or 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 readOnly/idempotent/non-destructive, so the safety bar is low. The description adds real value beyond them by warning that associated files 'pueden tener permisos diferentes y no son necesariamente retroalimentación del docente' — a permission and data-provenance caveat an agent would otherwise not anticipate.

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 with the core scope stated first and the parameter caveat second. No filler; the only weakness is that the opening fragment omits a verb, which slightly reduces front-loaded clarity.

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

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

For a 2-parameter read tool with no output schema, the description covers the return contents and the file caveat, but omits the courseId format requirement and does not clarify how the result relates to attempt IDs the agent must already hold. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain includeAttemptFiles well (it additionally fetches associated files with possibly different permissions), but courseId — the only required parameter with a strict pattern — receives no explanation at all in either schema or 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?

The description names the resource and the returned content ('último intento accesible por actividad, nota y comentarios'), which lets an agent infer it retrieves feedback on an assignment attempt. However, it is a noun phrase with no verb and no explicit differentiation from close siblings such as blackboard_get_attempt or blackboard_list_attempt_files, leaving the exact operation ambiguous.

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

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

There is no statement of when to use this tool versus the many sibling tools (get_attempt, list_attempts, list_attempt_files, get_grade_detail). The only conditional guidance is the includeAttemptFiles caveat, which is about a parameter rather than tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral note, 'respeta los permisos de la cuenta', which flags an authorization constraint, but says nothing about failure modes or scope of the openWorldHint.

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 the action and lookup key front-loaded and no filler. It is efficient, though arguably under-specified rather than optimally 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?

With no output schema, three undocumented required parameters, and no annotation coverage of return shape, the description is too thin for a tool whose entire contract is the three opaque IDs. It should at least state what an attempt is and what the call returns.

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 all three parameters (courseId, columnId, attemptId) are undocumented in the schema. The description only says lookups happen 'mediante sus IDs' without mapping which IDs are required or noting the '^_\d+_\d+$' format constraint, so it fails to 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 states a specific verb ('Consulta') and resource ('un intento ya existente'), and 'mediante sus IDs' clarifies the lookup key. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling blackboard_list_attempts.

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

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

The phrase 'ya existente' hints that this is for an already-created attempt rather than listing attempts, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as blackboard_list_attempts.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true. The clause 'no modifica citas' merely restates the read-only hint and adds no new behavioral context such as error behavior when an event ID is stale or what the detail payload contains.

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

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

A single dense sentence, front-loaded with the operation and followed by the two facts that matter (key source, side-effect-free). No filler.

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

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

With no output schema, the description should convey something about the returned detail, and it does not. For a simple two-parameter read whose safety profile is carried by annotations, it is adequate but leaves the return shape and failure modes unexplained.

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 carries the burden, and it does identify both parameters and their origin (list_calendar output). However, it adds no meaning about the 'type' semantics beyond the enum values already in the schema, and nothing about the eventId format.

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 ('Detalle de un evento') and the lookup keys (tipo e ID), which cleanly distinguishes it from the sibling list_calendar that produces those keys. It does not contrast itself against other get_* siblings, 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?

The description tells the agent where the required arguments come from ('devueltos por list_calendar'), which implies a list-then-get workflow. It gives no explicit when-not guidance or alternatives, so 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that – no mention of auth requirements, rate limits, error behavior, or whether missing/inaccessible content is handled differently. It repeats only the return-content notion implied by the name.

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 short sentence, front-loaded with the resource being retrieved. It is efficient, though it wastes a little space enumerating 'contenido, actividad o documento' without clarifying the distinction.

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

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

No output schema exists and parameter coverage is 0%, so the description must carry more weight than it does. It never clarifies what distinguishes a 'contenido' from an 'actividad' or 'documento', how the IDs are sourced, or the relationship to list_contents/search_contents, leaving an agent with gaps for a two-required-parameter tool.

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

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

Schema description coverage is 0% and both parameters are required with an opaque Blackboard ID pattern (^_\d+_\d+$). The description provides no information about courseId or contentId, so it fails to compensate for the coverage gap; only the self-evident parameter names carry meaning.

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

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

The phrase 'Detalle y enunciado de un contenido, actividad o documento de una sección' does convey that this returns the detail/body of a single content item, but it is a noun phrase with no action verb and offers no differentiation from close siblings like blackboard_list_contents or blackboard_search_contents. An agent must infer that this is the single-item retrieval counterpart to those list/search 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?

There is no guidance on when to use this versus the many sibling retrieval tools. Nothing indicates it requires IDs obtained from list_contents/search_contents, nor any condition or exclusion that would route an agent here rather than elsewhere.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety and idempotency are covered. The description adds that it does not mark content as reviewed and that non-reviewable content is not treated as pending, which is useful behavioral context beyond annotations. However, it does not explain what the response looks like or any rate limits, so a 3 is appropriate.

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

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

Two concise sentences with no wasted words, front-loading the core action and then adding an important clarification. The structure is efficient and easy to parse, though it could be slightly more front-loaded by leading with the main action before the clarification.

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?

Given the tool has no output schema and low schema description coverage, the description should do more to explain what 'estado de revisión' entails (e.g., possible statuses) and when to use it. It covers the non-reviewable case but omits other contextual details like prerequisites or typical return values. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention courseId or contentId at all, leaving the agent to infer their purpose from names and patterns. However, the parameters are self-explanatory (courseId, contentId) and required, so the baseline of 3 for minimal viable parameter semantics is justified, though the description could have added value by explaining the ID format or 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?

States a specific verb ('Lee') and resource ('estado de revisión propio de un contenido'), clearly identifying it reads the review status of a content item. However, it does not distinguish itself from siblings like blackboard_get_content or blackboard_get_course_review_summary, so it falls short of a 5. The scope ('propio de un contenido configurado como revisable') is clear but the name already conveys most of this.

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 guidance on when to use this tool versus alternatives. It mentions that non-reviewable content is not interpreted as pending, which clarifies an edge case but does not tell the agent when to choose this tool over siblings like get_content or get_course_review_summary. No when-to-use or when-not-to-use statements are present.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on auth requirements, course-scope restrictions, or what 'detalle' actually comprises.

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 four-word phrase is front-loaded and contains no filler, so there is nothing to trim. However, its brevity reflects under-specification rather than efficient communication of the needed information.

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

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

With no output schema, the description carries the burden of explaining the return value, and it does not. For a tool sitting among many similar course-scoped getters, an agent cannot determine what it will receive or how it differs from blackboard_get_course_overview.

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 the single required courseId parameter, and the description does not compensate. It never mentions that the ID must match the unusual ^_\d+_\d+$ pattern, which is exactly the kind of constraint a caller needs stated.

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 phrase 'Detalle de un curso' essentially restates the tool name (get_course) without specifying what detail is returned. It does not distinguish this tool from near-neighbours such as blackboard_get_course_overview, blackboard_get_course_outline, blackboard_get_course_agenda, or blackboard_list_courses, leaving the agent unable to tell which course-detail endpoint 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. Given that roughly a dozen sibling tools return course-scoped information, the absence of any routing hint is a real gap, though the text is not actively misleading.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it merges two data sources and enforces a hard 112-day interval cap. It still omits pagination, return shape, and what happens if the interval is exceeded.

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

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

Two compact sentences, front-loaded with what the tool does and followed by the key scope limitation. No filler, though it trades brevity for missing detail elsewhere.

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

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

No output schema exists, so the description does usefully sketch the returned content (due dates + calendar events) and the interval bound. But with 0% schema coverage and no annotations explaining returns, the under-documented parameters and absent output/format details leave clear gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only implicitly conveys that since/until form the interval (with a 112-day max); it says nothing about the courseId format or the required date-time syntax, leaving most of the three required parameters unexplained.

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

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

States a specific verb+resource: it combines published activity due dates with calendar events. It also bounds the operation (up to 112 days) and scopes it negatively ('no determina tareas pendientes de entrega'). However, it never names or distinguishes itself from the several sibling agenda/calendar tools (get_multi_course_agenda, list_calendar, export_course_agenda).

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 negative 'no determina tareas pendientes' hints at a use boundary, but there is no explicit when-to-use, no prerequisites, and no alternative named. An agent cannot tell from this text when to pick this over blackboard_list_calendar or blackboard_get_multi_course_agenda.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description earns credit for adding behavior beyond that: it preserves null values and zero scores and deliberately does not compute weightings or averages, which materially shapes how an agent should interpret 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?

Two tight sentences with no filler; the aggregation scope is front-loaded and the negative constraint follows immediately. Appropriately sized for a single-parameter read tool.

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

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

For a read-only aggregation tool with no output schema, the description covers what is combined and what is deliberately not computed. It omits what the combined structure looks like and how the courseId maps to a section, leaving a modest gap for an agent needing to interpret the result.

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

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

There is one required parameter with 0% schema description coverage, so the description must carry the load and it does not mention courseId at all. The schema's pattern constraint (^_\d+_\d+$) is left unexplained, so an agent gets no help forming a valid identifier.

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 action (joining grades, columns and categories) on a specific resource (the section's gradebook), which is clearer than the tautological name alone. However, it never distinguishes itself from close siblings like blackboard_get_grades, blackboard_get_grade_columns, or blackboard_get_grade_categories, leaving an agent to infer that this is the aggregating view.

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 clause 'no calcula ponderaciones ni promedios' usefully signals when not to expect computed scores, and 'Une ... de la sección' implies when to use it as the combined view. But no alternative sibling is named and no prerequisite (e.g., enrollment, valid courseId) is stated, so the routing guidance is implied rather than explicit.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context beyond annotations: it discloses that the structure is recursive and bounded, includes paths and types, and emits truncation warnings when limits are hit.

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

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

The description is a single, front-loaded sentence that packs the core contract without waste. Every phrase adds information: recursive structure, bounded scope, paths, types, and truncation warnings.

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 three-parameter tool with 0% schema coverage and no output schema, the description leaves parameter meanings and usage conditions unexplained. It sketches the return shape but an agent would still not know how to supply courseId or how maxDepth and maxItems behave.

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 the description does not name or explain courseId, maxDepth, or maxItems. 'Acotada' hints that some bounding parameters exist, but it gives no detail about courseId's required pattern or how the depth/item limits affect results.

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 and output shape: a bounded recursive structure of folders and contents with paths, types, and truncation warnings. It is clear what the tool returns, though it does not explicitly name a sibling tool to distinguish it from alternatives like list_contents or export_course_outline.

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 provides no when-to-use guidance, prerequisites, or alternatives. It does not say when to choose this tool over blackboard_list_contents, blackboard_get_content, or blackboard_export_course_outline.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds a useful behavioral detail: it flags inaccessible sources ('señala fuentes no accesibles'). No other traits like authentication needs, rate limits, or failure modes are given.

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

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

One compact sentence with the main action front-loaded and no redundant wording. It is appropriately sized for the information provided.

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 an aggregator tool with one undocumented parameter and no output schema, the description is too thin. It does not clarify the scope of 'detalle del curso' or how the flagged inaccessible sources affect results, leaving 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?

Schema description coverage is 0% and the single required parameter courseId is not mentioned in the description. The unusual pattern (^_\d+_\d+$) is undocumented, leaving the agent without format 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?

Specific verb 'Reúne' and enumerates resources (course detail, announcements, root contents, activities, grades), making the aggregation scope clear. However, it does not explicitly differentiate from siblings like blackboard_get_course or blackboard_get_course_review_summary, which also deal with course-level data.

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

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

No guidance on when to use this tool over alternatives; it only states what it aggregates. The condition for selecting an overview versus a focused tool is left entirely 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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description's one contribution is the negation that it does not mark reviews or compute academic progress, which is a minor scoping disclosure; it says nothing about the bounded traversal, pagination, or response shape.

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 no padding, and the purpose statement is front-loaded ahead of the exclusion. It is appropriately sized but the terseness comes at the cost of under-specification rather than being crisp.

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, 0% parameter coverage, and three undocumented inputs, the description carries the full burden but supplies almost nothing. An agent lacks the information to call this correctly or distinguish it from the sibling review-status tool.

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

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

Schema description coverage is 0% across all three parameters, so the description must compensate and does not. The phrase 'recorrido acotado' faintly hints at the maxDepth/maxItems bounding parameters but never explains their meaning or effect, and the courseId pattern is 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 ('Estados propios de los contenidos configurados como revisables en un recorrido acotado') never states a clear verb+resource; it gestures at 'states of reviewable content' without saying what a 'review summary' actually returns. It reads as an abstract restatement of an opaque concept rather than a distinguishable purpose, especially against the near-identical sibling blackboard_get_content_review_status.

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 only guidance is a negative clause ('No marca revisiones ni calcula progreso académico'), which tells the agent what the tool is not but gives no positive when-to-use signal. It never contrasts itself with blackboard_get_content_review_status or blackboard_get_content_review_status, leaving selection ambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds no behavioral context of its own (no auth requirements, no visibility/access rules despite saying 'accesible', no return shape). It also switches to Spanish while the rest of the tool surface is English, which adds ambiguity rather than clarity.

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 short, but the brevity comes from under-specification rather than efficiency; the single sentence conveys almost no actionable information. Brevity that omits the verb, scope, and parameters does not earn 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?

With no output schema and no parameter documentation, the description is the only place an agent could learn the return shape and ID conventions, and it supplies neither. A read tool with two required opaque ID parameters needs at least that much.

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, and the description mentions neither courseId nor discussionId, nor the required '^_\d+_\d+$' ID format. With the schema carrying all semantic weight and the description contributing nothing, it fails to 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 is a noun phrase ('Detalle y tema publicado de una discusión Ultra accesible') with no verb, essentially restating the tool name blackboard_get_discussion. It never distinguishes this tool from close siblings like blackboard_list_discussions, blackboard_list_discussion_messages, or blackboard_list_discussion_replies, so an agent cannot tell whether it returns a discussion container, its messages, or its metadata.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only implied context is that it fetches a discussion, which an agent could already infer from the name. Nothing routes it against list_discussions or list_discussion_messages.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that percentages are not provided and the final grade is not calculated, which helps set expectations about the output, but other behavioral aspects like pagination or permission requirements are not mentioned.

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

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

The description is a single, compact sentence that is front-loaded with the core information and includes a relevant exclusion. It is efficient and every part 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 simple read-only tool with one parameter and no output schema, the description adequately conveys what the tool returns and what it does not. However, it omits any note on when to use it or how to format the courseId, leaving gaps that could affect 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?

With one parameter (courseId) and 0% schema description coverage, the description does not compensate by explaining the parameter's format or constraints. The pattern '^_\d+_\d+$' is visible only in the schema, and a brief note about the expected format would have added value.

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 ('Categorías publicadas del libro de notas') and clarifies what is returned ('id y título'). It distinguishes itself from siblings like blackboard_get_grade_columns and blackboard_get_grades by focusing on categories, though it doesn't explicitly name alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives such as blackboard_get_grade_columns or blackboard_get_course_gradebook. It only states what the tool does, not the context in which it should be invoked.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful content caveat: the result does not necessarily include syllabus weightings, warning the agent not to assume grading weights are present. It says nothing about return shape or pagination, so it stays at a moderate level.

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 no filler, and the primary content claim is front-loaded ahead of the caveat. It is efficient, though borderline terse for a tool whose schema is undocumented.

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

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

For a one-parameter read tool with no output schema, the description covers what the tool returns and one important limitation. It is adequate but leaves the only parameter undocumented and does not describe the shape of the returned columns.

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 the single courseId parameter has only a regex pattern, no prose. The description supplies no information about the parameter's expected format or source, so it fails to compensate for the schema 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 identifies the resource precisely: grade columns and their maximum scores ('Columnas de calificaciones y puntajes máximos'), which separates it from sibling tools like get_grade_categories, get_grades, and list_grade_periods. It lacks an explicit verb, but the noun phrase is unambiguous about what is returned.

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. The caveat about syllabus weightings hints at a boundary with syllabus-related tools, but it never names the alternative tool or the condition under which an agent should prefer 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine context beyond them: it warns that grade.status is an unreliable historical field and that this tool does not compute final grade or submission status, which forecloses a real misinterpretation of the returned 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?

Two sentences, front-loaded with the returned fields before the reliability caveat. Every clause earns its place; only the terse enumeration of fields borders on list-like density.

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

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

No output schema exists, so the description carries the return-value burden and does so reasonably by naming the main fields returned plus a reliability warning. It leaves parameter usage under-specified, but the core picture is complete for an agent to call it.

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

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

Schema description coverage is 0% across three parameters. The description alludes to the column ('nota propia de una columna') and to attempts ('intentos accesibles'), hinting at includeAttempts, but never explains the required courseId/columnId ID format or what includeAttempts toggles, 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?

States a specific verb and resource: returns the student's own grade for a single column, enumerating what it contains (displayGrade, comments, exemption, metadata, accessible attempts). This is clearly differentiated in substance from sibling grade-list tools, though it never names an alternative like blackboard_get_grades or blackboard_get_grade_columns to route the agent explicitly.

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

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

There is no when-to-use or when-not-to-use guidance relative to siblings. The closing clause 'no calcula nota final ni estado de entrega' is a scope caveat about outputs, not a usage rule, so the agent must infer appropriateness 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing on top of that — no note on whose grades are returned, auth requirements, or scoping behavior, despite openWorldHint suggesting external data fetching.

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 short, front-loaded fragment with no wasted words, which is good. But brevity here reflects under-specification rather than disciplined conciseness, so it sits at the minimum viable level.

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 0% parameter coverage, the description carries the full burden of explaining input and return behavior, and it does neither. For a tool requiring an opaque courseId, this is insufficient to call the tool correctly.

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 the single required courseId is only constrained by a regex pattern (^_\d+_\d+$). The description never explains what courseId is, where to obtain it, or its expected format, so it fails to compensate for the schema 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 names the resource (grades) and scope (a student in a course), which is more specific than the bare tool name. However, it does not distinguish itself from close siblings like blackboard_get_grade_detail, blackboard_get_course_gradebook, or blackboard_get_multi_course_gradebook, so an agent cannot confidently route between them from the text alone.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is left to infer that this is the single-course grade lookup versus the multi-course or detail variants.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds that the result is limited to published configuration and does not assert membership, which is modest extra context but no detail on access requirements or staleness 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?

Two tight sentences with no filler; the positive scope is front-loaded and the caveat follows. Efficient, though extremely terse for a tool with zero parameter documentation.

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?

There is no output schema, so the description should ideally hint at what the returned configuration contains, and the two required identifier parameters are unexplained. It is adequate but leaves notable gaps for an agent to fill.

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 both courseId and groupId carry only a regex pattern with no textual explanation. The description does not mention either parameter, so it fails to compensate for the documentation 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?

Names the resource (a group) and the specific facets returned: description, availability, and published configuration, plus the access qualifier 'accesible'. It is clearly distinct from siblings like list_groups or get_my_enrollment, though the verb itself is implicit rather than stated.

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 closing clause 'No acredita pertenencia ni cambia la inscripción' implicitly scopes the tool away from membership/enrollment lookups, which is useful negative guidance. However, it never states when to prefer this over list_groups or list_group_sets, so usage 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?

Annotations already declare readOnly/idempotent/openWorld and non-destructive; the description adds real behavioral context beyond them: the 112-day window cap, the per-course announcements included, and two explicit non-behaviors. It stops short of describing return shape or ordering rules, but adds meaningful value over 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?

Two dense, front-loaded sentences with no filler; the scope, limits, and exclusions are packed efficiently, though the exclusions sentence could be slightly tighter.

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, so the description should be self-sufficient, and it mostly is: scope, quantity limits, date cap, and exclusions are all covered. Missing only explicit mention of the since/until parameters and the per-course grouping/ordering format.

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 carries the burden. It clarifies courseIds semantics (by ID, 1-10, matching maxItems=10) and implies a bounded date range via 'Máximo 112 días', but never names since/until or explains their format/relationship, leaving a partial 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?

States a specific verb+resource: a combined, ordered agenda over 1-10 courses selected by ID. The '1 a 10 cursos' scope clearly differentiates it from the single-course blackboard_get_course_agenda sibling, 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?

Gives operative constraints (max 112 days, 1-10 courses) and two exclusions ('no determina entregas pendientes', 'no mezcla secciones por nombre'), which imply when it is and isn't appropriate, but never states an explicit when-to-use condition or names an alternative tool.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: warnings are provided per source, sections are not merged, and no overall average is computed.

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

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

The description is two short sentences with no wasted words. The main action and scope are front-loaded, and the exclusion clause is compact and useful.

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?

Given the rich annotations and the absence of an output schema, the description is largely complete for selecting and invoking the tool. It covers scope and key behavioral exclusions, though the phrase 'avisos por fuente' remains somewhat vague about what warnings will be returned.

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 courseIds parameter. It communicates that 1–10 courses are selected by ID, which is useful, but it does not explain the ID format (e.g., the ^_\d+_\d+$ pattern) or give additional syntax 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?

The description states a specific verb (Consulta) and resource (libros de notas) with a clear multi-course scope of 1–10 courses by ID. It distinguishes the tool from single-course gradebook tools by its multi-course range and from aggregate tools by explicitly saying it does not mix sections or calculate an overall average, though it does not name an alternative sibling.

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

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

The description implies usage for retrieving gradebooks from multiple courses chosen by ID and notes exclusions such as not mixing sections or calculating an overall average. However, it does not explicitly state when to choose this tool over siblings like get_course_gradebook, export_multi_course_grades, or get_multi_course_overview.

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 read-only, idempotent, non-destructive, and open-world behavior. The description adds that partial results are preserved per section, which is useful behavioral context beyond the annotations. However, no information is given about authentication requirements, rate limits, or how failures are surfaced.

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

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

The description is a single, compact sentence that front-loads the scope ('1 a 5 cursos') and lists the included sections, with no redundancy. It is efficient, though the partial-result note is slightly tailed and could be clearer.

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 batch, read-only overview tool with annotations covering safety and no output schema, the description conveys enough to understand the scope. Missing are explicit parameter guidance (courseIds format and limits) and differentiation from similar single-course or listing siblings.

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

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

Schema coverage is 0% and the description does not mention the courseIds parameter, its required status, the array constraint (1–5 items), or the expected ID pattern. With the schema providing no descriptions and the description silent, the parameter is effectively undocumented in natural language.

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 ('Panorama de 1 a 5 cursos') and enumerates what it includes (anuncios, raíz de contenidos, actividades, notas propias). It is understandable as a multi-course overview tool. However, it does not explicitly distinguish itself from siblings like blackboard_get_course_overview or blackboard_list_courses, weakening 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 description mentions '1 a 5 cursos elegidos' and partial result retention, implying batch use, but provides no explicit when-to-use, when-not-to-use, or guidance on choosing this over blackboard_get_course_overview or blackboard_list_courses. Usage remains inferred at best.

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 idempotentHint=true, so safety is covered. The description adds valuable behavioral context: absence is represented as null rather than an absence mark, and it notes that inaccessible sources are flagged—information not in the schema or 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?

The description is three short sentences, front-loaded with purpose and then behavioral notes. It is efficient with no obvious filler, though slightly fragmented across clauses.

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

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

For a read-only tool with no output schema and one parameter, the description covers key behavioral nuances (null for missing, inaccessible sources). However, it omits parameter format details and usage context relative to siblings, leaving some 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?

With schema description coverage at 0% and one required parameter (courseId) having a pattern but no textual explanation, the description should compensate. It only mentions filtering by session IDs without explaining that courseId determines the session set or describing the required pattern format, leaving a 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 states a specific verb+resource: retrieving the current account's attendance filtered by this course's session IDs. It is reasonably clear, though slightly less direct due to the phrasing 'Asistencia de la cuenta actual' and lacks explicit differentiation from siblings like export_attendance.

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 guidance on when to use this tool versus alternatives such as export_attendance or how the session IDs are obtained. Usage is implied by the filter description but no when/when-not conditions or alternatives are named.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds a scope caveat (not an academic registration record, no payments/credits), which is genuinely useful for interpreting results, but says nothing about auth requirements or return shape.

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, front-loaded with what is returned and followed by the scope exclusion. No filler; could be slightly clearer about courseId but is well structured.

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

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

For a single-parameter, no-output-schema read tool with full annotation coverage, the description adequately states what is returned and what is out of scope. The only gap is courseId semantics, which the schema pattern partially 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?

Schema description coverage is 0% and the single courseId parameter carries only a regex pattern, so the description must compensate. It only implies 'un curso', adding no format, source, or semantics for courseId beyond what the pattern hints at.

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 clear resource (inscripción/rol/condiciones of the current account in a course) for a specific verb of retrieval. It distinguishes itself from gradebook/attendance/content siblings by scoping to enrollment data, though it never names a sibling directly.

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

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

The negative clause ('No certifica matrícula académica ni consulta pagos o créditos') tells the agent when this tool is not appropriate, which is useful. However, it gives no positive usage context or names no alternative tool for the excluded cases, so routing 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description does add genuine behavioral value by disclosing limitations ('no supone tareas pendientes ni inventa disponibilidad de estudio') and that output carries sources and warnings, which tells the agent the result is bounded and cited rather than inferred.

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 core content statement front-loaded and the caveat second; nothing is padded. Slight deduction because the disclaimer occupies half the text without clarifying the tool's operation.

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

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

With three undocumented required parameters and no output schema, the description should carry more of the burden. It never explains what the brief actually contains, how the date range is applied, or what 'avisos' means in practice, leaving the agent under-informed for a tool that is not trivially self-explanatory.

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 all three required parameters, so the schema documents nothing. The phrase 'basado en fechas publicadas' loosely hints at the since/until range but gives no format, timezone, or inclusivity semantics, and courseId (with its '_N_N' pattern) is entirely unexplained.

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

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

The description names a content type (a summary grounded in published dates and syllabus candidates, with sources and warnings), but the noun 'Resumen' is vague about the actual operation and does not distinguish this from close siblings like blackboard_export_study_brief, blackboard_get_course_agenda, or blackboard_get_course_outline. An agent can guess the domain but not the distinct 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?

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative blackboard_export_study_brief or the agenda tools. The only scoping statement is a negative disclaimer about what the tool won't do, not about when to pick 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 cover readOnly, idempotent, and non-destructive, so safety is clear. The description adds that it does not create receipts, but doesn't explain what a receipt contains, whether it requires specific permissions, or any rate limits. Marginal 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, front-loaded with the core purpose and followed by an important caveat. No unnecessary words, though the caveat could be clearer.

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, 0% parameter coverage, and no annotations beyond safety. The description is insufficient for an agent to understand what a receipt looks like, how to interpret empty results, or what the parameters mean in practice.

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 only mentions 'una actividad' (an activity) and implies course context, but doesn't explain the two required parameters (courseId, columnId) or their patterns. Significant 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?

States it returns published receipts ('Comprobantes publicados') for attempts in an activity, but the phrase is generic and doesn't clearly distinguish it from siblings like blackboard_list_attempts or blackboard_get_attempt. An agent can infer it's about submission receipts, but the verb+resource pairing is vague.

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?

Includes a caveat about absent receipts not proving non-submission, which implicitly tells the agent when NOT to conclude something. However, there's no explicit when-to-use guidance or mention of alternatives like blackboard_export_submission_receipts or blackboard_get_attempt.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds real behavioral constraints: it rejects external paths and explicitly does not verify hashes or remote content. It does not describe the return shape (a mild gap for a check-style 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?

Two tight sentences with no waste; the core action is front-loaded and the limitations follow immediately after.

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

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

No output schema exists, so the description carries some return-value burden it does not meet, and the one input parameter is left undefined. The scope limitations it does provide are useful but the definition is only partially complete for an agent to call it correctly.

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 required parameter 'path' has 0% schema description coverage, and the description never clarifies what the path points to (the manifest.json itself, or a directory containing it) or its accepted format. With low coverage the description is expected to compensate, and it does not.

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: verifies existence and size of downloads referenced by a local manifest.json. This clearly distinguishes it from the sibling read/list/search downloaded-material tools, though it never names 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?

Usage is implied by the purpose plus two scope exclusions (rejects external paths, does not verify hashes or remote content), which help bound when it applies. However, there is no explicit when-to-use guidance or routing to siblings such as blackboard_read_downloaded_material.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing beyond that — no mention of pagination, result scope, ordering, or the course-scoped nature of the listing.

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 words is terse, but this is under-specification rather than genuine conciseness. There is no front-loaded statement of what the tool does or returns, so the brevity conveys no value.

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, no parameter documentation, and only annotation hints for behavior, the description must carry the burden — and it does not. An agent cannot tell what this returns, how it differs from get_announcement or search_announcements, or what courseId should look 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?

The single required parameter courseId has 0% schema description coverage, so the schema provides no explanation of its meaning or the '^_\d+_\d+$' pattern. The description does not compensate at all — it never mentions courseId, its required status, or its format.

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 'Anuncios del curso' is a noun phrase that essentially restates the resource already implied by the name 'blackboard_list_announcements'. It adds a scope qualifier ('del curso') but no verb, and does nothing to distinguish it from siblings like blackboard_search_announcements, blackboard_get_announcement, or blackboard_list_institution_announcements.

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 whatsoever about when to use this tool versus the many sibling announcement tools (search_announcements, get_announcement, list_institution_announcements, search_multi_course_announcements). No prerequisites, no context, 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds real behavioral context beyond that: results are limited to Attempts/Manual grading types, only published dates and scores are returned, and it explicitly does not resolve missing submissions. It stops short of describing return shape or pagination.

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

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

It is a single compact sentence with no filler, which is good, but the telegraphic style and the language mismatch with the rest of the toolset (English names/siblings) make it hard to parse quickly. Conciseness is achieved at the cost of 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?

There is no output schema and no annotation-level detail about results, so the description should carry more weight than it does. It does disclose the grading-type filter and the missing-submission limitation, but omits any description of returned fields, ordering, or the courseId parameter, leaving gaps for an agent that must call it blind.

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 the single required courseId (with pattern ^_\d+_\d+$) is never mentioned in the description. With one undocumented parameter, the description provides no format or meaning cues to compensate for the schema 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 fragment 'Actividades evaluables' names the resource (gradable assignments) and narrows scope to Attempts/Manual grading types, but it never supplies a verb (list/retrieve) and is written as a compressed noun phrase rather than a statement of what the tool does. An agent must infer the 'list' behavior from the tool name alone.

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

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

'no determina si falta entregar' is a genuine negative constraint that tells the agent not to rely on this tool for missing-submission detection, which is useful routing information. However, it names no alternative tool and gives no positive 'use this when...' condition, so the guidance is only half-complete.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not say whether results are paginated, whether it follows content hierarchy, or how embedded files differ from REST attachments, so it contributes essentially no behavioral context.

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 short noun phrase with no padding, so there is no waste, but it is under-specified rather than concise. Nothing is front-loaded because there is nothing to front-load: no verb, no scope statement, no constraints.

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

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

With no output schema, the description carries the burden of explaining what is returned, and it does not. For a two-required-parameter tool with a strongly patterned identifier requirement and multiple overlapping sibling tools, this definition omits both parameter semantics and return-format information an agent needs to call it correctly.

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 required parameters, which are only constrained by a regex ('^_\\d+_\\d+$'). The description never mentions courseId or contentId or explains the required identifier format, so it fails to compensate for the documentation gap even though 'un contenido' faintly gestures at contentId.

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 phrase names the resource ('adjuntos REST y archivos incrustados de un contenido') but supplies no verb, and read as a noun phrase it largely restates the tool name blackboard_list_attachments. It does add the scope detail that both REST attachments and embedded files are included, which is more than pure tautology, but it does nothing to separate this tool from siblings such as blackboard_list_attempt_files, blackboard_list_course_files, or blackboard_list_contents.

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 call this tool versus the many sibling listing/downloading tools (blackboard_download_attachment, blackboard_list_course_files, blackboard_list_contents). No prerequisites, no workflow context, and no stated exclusions are given; the agent must infer everything from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds a genuine behavioral disclosure beyond the structured fields: returned files are not automatically classified as teacher corrections, which affects how an agent should interpret results. It does not describe pagination or return format, but the output-semantics caveat is meaningful.

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

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

A single sentence, front-loaded with the action and then qualified with the key caveat. Efficient with no padding, though the trailing clause is slightly compressed for an English-speaking agent audience.

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 list tool without an output schema, the description does cover the safety profile via annotations and adds the correction-classification caveat. However, with three required patterned parameters at 0% description coverage and no mention of result shape or limits, it leaves gaps an agent must resolve from the schema alone.

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 3 required parameters (courseId, columnId, attemptId) documented only by regex patterns. The description mentions 'intento' which loosely maps to attemptId, but says nothing about the roles or formats of courseId/columnId, so it fails to 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?

States a specific verb+resource: 'Lista archivos asociados a un intento', naming the attempt-file relationship directly. It is distinguishable from siblings like blackboard_list_attachments and blackboard_get_attempt, though it does not explicitly name those alternatives. The added clause about not auto-identifying corrections clarifies scope rather than purpose.

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 attempt-scoped framing, but there is no explicit when-to-use or when-not-to-use guidance versus blackboard_list_attachments or blackboard_get_attempt. The negative clarification about 'correcciones del docente' is a semantic caveat, not an alternative-selection 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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context such as what an attempt contains, whether results are paginated, or any permission requirements.

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 only four words long. While it is front-loaded, it is under-specified rather than concise: it omits essential information that an agent needs to invoke the tool correctly.

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

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

For a tool with two required parameters, 0% schema description coverage, and no output schema, the description is entirely inadequate. It leaves parameter meaning, usage context, and return behavior completely unexplained.

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 the description does not mention either required parameter. The words 'de una tarea' hint at a task context but do not explain that courseId and columnId are required identifiers, nor do they clarify their format or relationship.

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 'Intentos de una tarea' identifies the resource (attempts) and its parent (a task), but it is a noun phrase with no verb and no scope details. It does not clearly differentiate itself from siblings like get_attempt or list_attempt_files beyond the plural/singular 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?

The description provides no guidance on when to use this tool, when not to use it, or which alternatives exist. It does not mention prerequisites, contexts, or any condition for selecting this tool over get_attempt or list_attempt_files.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered externally. The description adds one genuinely useful behavioral fact beyond annotations: only *published* events are returned and the result is not the full academic schedule. It says nothing about pagination, ordering, or result limits.

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 front-loads the resource and scope before the disambiguating caveat. Nothing is wasted, though the sentence packs two distinct ideas without separating them.

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

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

For a read-only listing tool with no output schema, the description is minimally adequate: it covers the range semantics and the scope caveat. But with 0% schema coverage it should also explain the courseId filter, and it gives no hint about return volume or pagination.

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 carries full burden for three parameters. It loosely identifies the two date parameters via 'entre dos fechas ISO 8601', but the optional courseId filter is never mentioned in either the schema or the description, leaving a third of the parameters 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 (eventos publicados en el calendario de Blackboard) and a scope (between two ISO 8601 dates), which distinguishes it from the surrounding listing tools. It stops short of an explicit verb and never names the sibling it is not, but an agent can still tell it apart from a course-meetings/schedule tool.

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 clause 'no representa el horario académico completo' implies the boundary against the academic-schedule tool (e.g. blackboard_list_course_meetings), but the alternative is never named and no positive when-to-use condition is given. Usage is only inferable, not stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's burden is lower. It adds the account-scoping and the 'not the complete academic schedule' caveat, but says nothing about return shape or how many calendars to expect.

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, both earning their place: the first states what it returns, the second routes to the alternative and sets expectations. Front-loaded and free of padding.

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, read-only listing tool with no output schema, the description supplies enough to call it correctly and to know it is not a substitute for the academic schedule. Only the return-value shape is unaddressed, which is 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?

This tool takes zero input parameters, so there is no parameter semantics to document; the baseline for a parameterless tool is 4.

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

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

States a specific verb and resource: it lists the calendars visible to the current account. It also distinguishes itself from the sibling blackboard_list_calendar by clarifying that this tool returns calendars, not events. Lacks an explicit account/course scope beyond 'current account'.

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 routes the agent to list_calendar for event retrieval and warns that this is not the full academic schedule, so when-to-use and when-not-to-expect are both implied. No step-by-step prerequisites, but the alternative tool is named clearly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that—no pagination, no scope limits, no note on what a 'carpeta' (folder) id implies versus a course id.

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 short, but brevity here reflects under-specification rather than economy—a single noun phrase with no verb, no front-loaded action, and no structure to guide an agent. Not a case of efficient 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?

For a listing tool with no output schema, 0% parameter coverage, and a large sibling set, the description omits return shape, pagination, and how courseId vs parentId scope the results. An agent has enough to guess but not enough to invoke confidently.

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 two parameters, so the description must compensate. It only loosely hints that one parameter is a course and another a folder ('curso o carpeta'), without mapping to courseId/parentId, stating the required vs optional distinction, or explaining the opaque _\d+_\d+ id pattern.

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 phrase 'Materiales de un curso o carpeta' names a resource (course/folder materials) and implies a listing operation, but the verb is absent and there is no differentiation from close siblings like blackboard_list_course_files, blackboard_list_attachments, or blackboard_get_content. An agent cannot tell from the text alone which of these retrieves what.

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 indication of when to prefer this over the many sibling list/get tools, and no prerequisites stated. The only implied usage is 'when you want materials', which is too weak to route selection among ~60 siblings.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds meaningful context beyond that: it is recursive, spans two file sources, and returns paths and IDs, plus the explicit note that it neither downloads nor reads file contents.

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 with no waste: scope first (what is inventoried and what is returned), then capability and boundary. 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?

For a 5-param read-only listing tool with no output schema, the description covers source scope, return shape (paths, IDs), filtering, and the read-only boundary; annotations cover safety. Minor gap is that recursion/result limits and default behavior aren't mentioned, but the schema handles those.

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 80%, so the schema carries most parameter meaning (maxDepth, maxItems, maxResults all documented there). The description only adds that filtering is by name extension, mirroring the extensions param without new detail, so baseline 3 applies.

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

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

States a specific verb+resource: a recursive inventory of two distinct file sources (REST attachments and embedded bbcswebdav files) with paths and IDs. This differentiates it from download/list siblings, though it doesn't explicitly name blackboard_list_attachments, which is its closest relative.

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 clause 'no descarga ni lee archivos' effectively signals when NOT to use this tool (i.e. use a download/read tool instead), and the extension filter hints at a common use case. However, no alternative tool is named and no explicit when-to-use framing is given, leaving routing 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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: it clarifies that despite the open-world hint it 'does not open or authenticate external services', which tells the agent no outbound calls or credentials are involved, and it specifies the sources it scans (pages and contentHandler.url).

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 with zero filler, leading immediately with what is collected and closing with the negative capability that constrains interpretation. 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?

There is no output schema, so the description correctly sketches the return shape (links with route and origin), and annotations carry the safety profile. Still missing is any usage context or note on result limits/pagination interaction with maxResults, leaving the agent with an adequate but not fully complete picture.

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 75% (maxDepth, maxItems, maxResults all documented with defaults), so the schema does most of the work. The description contributes nothing about parameters — courseId's format and the crawl-limit semantics are handled entirely in the schema.

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

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

The description names a specific resource (HTTP/HTTPS links found in course pages and contentHandler.url) and its scope (path plus internal/external origin), so the agent knows what kind of output to expect. It does not, however, contrast itself with adjacent tools like list_attachments, list_course_files, or list_contents, so 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?

There is no when-to-use guidance and no mention of alternatives such as list_contents or list_course_files. The agent must guess when link extraction is preferable to generic content listing.

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 establish read-only, idempotent, non-destructive, open-world behavior. The description adds an important semantic caveat beyond annotations: these are attendance-tool sessions, not the full academic schedule, and they do not confirm presence. It still omits pagination, auth, or return-shape details.

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, both earning their place: the first defines the resource, and the second immediately states the key limitation. It is appropriately sized and front-loaded.

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 simple and annotations cover safety behavior, while the description usefully clarifies data scope. However, the required courseId remains undocumented in both schema and description, leaving an agent without enough information about the parameter to invoke the tool confidently.

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

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

There is one required parameter, courseId, and schema description coverage is 0%. The description never mentions courseId, its meaning, or the expected ^_\d+_\d+$ format, so it does not compensate for the missing schema 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 the resource clearly: sessions recorded in the course attendance tool. It also distinguishes the scope from the full academic schedule and from presence confirmation, but it lacks an explicit action verb such as 'list' or 'retrieve'.

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 is not, which helps avoid confusion with schedule or attendance-confirmation data. However, it does not say when to use this tool versus alternatives such as blackboard_get_my_attendance, calendar tools, or agenda tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds that results are constrained by Blackboard permissions, a useful behavioral note, but says nothing about pagination, result size, or whether an empty list is possible.

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 tight sentence with no filler, and the scope constraint is stated immediately. It reads as a label fragment rather than a complete sentence, which slightly weakens front-loading of the 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 parameterless list tool with no output schema, an agent would benefit from knowing the shape of each returned course (id, name, enrollment info) to chain into other calls. The description covers the filtering rule but omits the return shape and any pagination 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are missing.

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

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

States the resource (courses) and its scope (those tied to the authenticated account), which is enough to separate it from single-course siblings like blackboard_get_course. It is a noun phrase rather than a verb+resource statement, so the 'list' action is only implied by the name, but the intent is unambiguous.

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

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

No guidance on when to choose this over the ~70 siblings. There is no mention of alternatives (e.g., blackboard_get_course for a single course) or of prerequisites such as needing to be logged in 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?

Annotations already cover readOnly, idempotent, and non-destructive, so the bar is lower. The description adds genuinely new behavior: it respects Blackboard group/permission scoping and does NOT mark messages as read — a side-effect note the annotations cannot express.

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, dense statements with zero filler; the default-value fact and the onlyMine behavior are front-loaded before the permission caveat.

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 list tool with no output schema, the description covers scoping, default filtering, and side effects. It omits pagination/result-size behavior, but nothing required 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 0% across 5 parameters, but courseId, discussionId, and groupId are self-describing. The description disambiguates onlyMine and states the status default, yet leaves the Deleted/Draft enum values and the groupId pattern unexplained.

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

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

Names a specific verb+resource ('Mensajes accesibles de una discusión Ultra'), and specifies the default scope ('publicados por defecto'). It implicitly distinguishes a message listing from sibling blackboard_list_discussion_replies, but never names that sibling or clarifies the boundary 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?

Gives useful selection context: default status is 'Published' and onlyMine narrows to the current account. However, it never says when to prefer this over blackboard_list_discussion_replies or blackboard_get_discussion, so the agent must infer routing from tool names alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description reinforces this by stating it does not send replies, and adds that parentId and threadId are preserved in the returned data. It does not mention authentication, pagination, or rate limits, so it adds some but not rich behavioral context beyond 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?

Two short sentences with no filler; the core return behavior is front-loaded and the negative constraint follows immediately. It is efficient, though it could be slightly more structured by explicitly naming the operation as a list. No sentence is wasted.

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

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

For a tool with six parameters, three required, no output schema, and 0% schema description coverage, the description is far too sparse. It does not document most parameters, does not explain return shape beyond parentId/threadId preservation, and provides minimal usage context. The annotations help with safety, but the overall definition is incomplete 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?

Schema description coverage is 0% across six parameters, so the description must compensate. It implies the need for a message and implicitly a discussion/course, but says nothing about status, groupId, onlyMine, or the required courseId/discussionId/messageId patterns. Most parameter semantics are left undocumented in both the schema and 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?

The description states a specific resource (accessible replies to an Ultra discussion message) and scope (preserving parentId and threadId). It distinguishes from sending replies, but does not explicitly contrast with blackboard_list_discussion_messages or blackboard_get_discussion, which are close siblings. The core purpose is still clear enough for an agent to identify it as a list operation.

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 includes one negative guideline: 'No envía respuestas' (does not send replies), which helps avoid misusing it as a write tool. However, it offers no positive when-to-use guidance or explicit alternatives among the many sibling discussion tools. Usage is therefore 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?

Annotations already declare the read-only, idempotent, non-destructive profile, so the bar is lower. The description adds genuine context beyond that: results are limited to Ultra courses and Original-course forums are not guaranteed, plus it explicitly clarifies it does not post messages. This is useful scoping behavior not captured by 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 compact sentences with the core purpose front-loaded and the filtering/limits stated right after. No filler, though the phrasing packs several constraints into the second clause.

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

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

Covers purpose, filters, and key limitations, and since no output schema exists the description needn't detail return values. It is nonetheless incomplete on the required courseId format/scope and on what the listing returns, which matters for a filterable list tool.

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

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

Schema description coverage is 0%, so the description must compensate. It names two filters (título, evaluables) matching the title and gradable params, but says nothing about the required courseId or its required _X_Y pattern, leaving one of three parameters unexplained.

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

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

States a specific verb+resource: listings of accessible discussions in an Ultra course, with filtering. It implicitly distinguishes itself from siblings like blackboard_list_discussion_messages and blackboard_get_discussion by noting it does not publish messages, though it does not name the alternatives 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?

Provides some when-not guidance ('no publica mensajes', 'no garantiza foros en cursos Original'), which scopes usage. However, it does not name explicit alternatives or state when to prefer a sibling tool, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context beyond annotations: it is a local inventory, requires no session, and does not download new files. It does not describe rate limits or permissions, but with annotations covering safety, this is solid additional context.

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. The purpose is front-loaded, and the second sentence adds a key behavioral constraint without restating the tool name or title.

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

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

For a list tool with no output schema, the description gives useful return-value hints (relative paths, sizes, readable formats). Annotations cover safety, but the three input parameters remain completely unexplained, leaving a notable gap for an agent that needs to set depth, file limits, or a subdirectory filter.

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

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

The schema has three parameters (maxDepth, maxFiles, subdirectory) with 0% description coverage. The description does not mention any of them or explain what they control, so it fails to compensate for the schema 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?

States a specific resource and scope: a local inventory of downloaded materials, including relative paths, sizes, and readable formats. It distinguishes itself from download tools by saying it does not download new files, but it does not explicitly differentiate from close siblings like search_downloaded_materials or read_downloaded_material.

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 when to use it: for local inventory without requiring a session or fetching new files. However, it does not name alternatives or state when to prefer search_downloaded_materials or read_downloaded_material instead, leaving usage guidance implicit rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description does add one genuinely useful behavioral fact not present in the annotations — that the returned list may be empty — but says nothing about ordering, pagination, or what a period record contains.

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

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

Two short sentences with no filler, front-loaded with the resource definition and followed by the disambiguating caveat. Structure is efficient, though the leading noun phrase is slightly weaker than a verb-first statement of purpose.

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 annotation coverage this is adequate, but with no output schema the description gives no hint of the return shape, and the lone required parameter's expected format is left entirely to the schema pattern.

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 the description never mentions courseId or its required '^_\d+_\d+$' format. With a single required parameter that the schema leaves undocumented, the description should compensate for the gap and does not; only the self-explanatory parameter name limits the damage.

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 — the evaluation periods configured in the course gradebook — which an agent can distinguish from other gradebook entities. It lacks an explicit verb (the 'list' action is only carried by the tool name) and does not differentiate from siblings such as blackboard_get_grade_columns or blackboard_get_grade_categories, so it falls short of a 5.

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

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

The second sentence ('no determina el periodo oficial de matrícula') implicitly scopes usage by ruling out the enrollment-period interpretation, but it never states when to call this tool versus a sibling, nor does it name any alternative. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds scope negatives (no membership resolution, no member listing, no enrollment), but says nothing about pagination, result volume, or permission requirements for a course-scoped listing.

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 the core capability front-loaded and the scope limits second. No filler, though the negation sentence is dense and could be sharper.

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

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

For a simple read-only list tool with annotations covering safety and no output schema, this is close to adequate, but with 0% schema description coverage the description should say more about the required courseId and what a returned 'group' contains (id, name, group set).

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 carry parameter meaning. It does explain two of three parameters implicitly — the name filter and the group-set membership filter ('inGroupSet') — but adds no detail for the required courseId beyond the schema's own pattern, and no filter-matching behavior (exact vs partial name).

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

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

The description names a specific verb+resource in Spanish: listing the groups queryable in a course, plus its name and group-set filters. It is distinguishable from blackboard_get_group (singular fetch) and blackboard_list_group_sets, though it does not name those siblings explicitly.

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

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

It draws clear boundaries by stating what it does NOT do — it does not determine your membership, list members, or enroll students — which steers the agent away from misusing this list operation for membership/member queries. It stops short of explicitly naming the alternative tools (get_group, list_group_sets) that would cover those cases.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld). The description adds one genuine behavioral fact beyond them: the listing 'no garantiza acceso a detalles o integrantes', warning that member/detail data may be unavailable. It says nothing about pagination, filtering, or when that limitation applies, so it adds some but not rich context.

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 no filler; the resource identification is front-loaded and the caveat follows. Terse without being padded, though the brevity contributes to the missing differentiation.

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

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

For a single-parameter read-only listing tool with no output schema, the description covers what is listed and one limitation, which is roughly the minimum. It omits the course-ID format and any routing guidance against the two group-related siblings, which an agent needs given the 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 description coverage is 0% and the description never mentions 'courseId'. The parameter name is self-explanatory, but the required pattern '^_\d+_\d+$' (an unusual course-ID format) is documented nowhere, so the description 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 identifies the resource ('Conjuntos de grupos publicados en un curso') and implies a listing operation, and the phrase 'mediante groups/sets' hints at the underlying endpoint. However, it never states the verb explicitly nor distinguishes this from the sibling 'blackboard_list_groups' (individual groups) or 'blackboard_get_group', so an agent must guess which listing tool 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?

There is no statement of when to use this tool versus 'blackboard_list_groups' or 'blackboard_get_group', and no prerequisites. The only guidance-like sentence is a caveat about the returned data, which is behavioral rather than usage-oriented.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld. The description adds a key behavioral note: an empty result does not imply a permissions error, which is useful context beyond annotations. It does not cover pagination or rate limits.

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 no filler. Purpose is front-loaded, followed by parameter notes and a behavioral caveat. Structure is efficient though the first sentence is slightly dense.

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 list tool with rich annotations and no output schema, the description covers purpose, optional parameters, and empty-result behavior. However, it lacks explicit sibling routing and detailed parameter semantics, leaving some gaps for an agent.

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 description must explain parameters. It mentions 'título y vencidos opcionales' (title and expired optional), mapping to the two parameters, but does not clarify defaults, matching behavior, or exact meaning of includeExpired.

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 it lists institutional announcements within Aula Virtual UP, differentiating by scope from course-level siblings via 'institucionales'. However, it does not explicitly name alternatives like blackboard_list_announcements, so sibling differentiation is implicit.

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

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

Mentions optional title and expired filters and warns that an empty result is not a permissions error, which helps interpret output. But it gives no guidance on when to choose this over other announcement tools such as search_announcements or list_announcements.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description adds genuinely non-derivable behavior: a local browser window is opened (so user interaction is required) and the password is neither received nor stored. That security disclosure is valuable beyond the structured fields, though nothing is said about session duration or failure modes.

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

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

Two short sentences, zero filler, with the primary action (opening the local window) front-loaded and the security caveat second. Every sentence 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 parameterless authentication tool with no output schema, the definition covers the essential agent-relevant facts: it is interactive (opens a window), it targets Aula Virtual UP, and it does not handle passwords. Only the authenticated/unauthenticated precondition and relationship to blackboard_logout are missing.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter semantics to explain, and the description correctly notes that no credentials are passed in.

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 + resource: 'Abre una ventana local para iniciar sesión en Aula Virtual UP' clearly states it opens a local window to authenticate against the Aula Virtual UP platform. It is distinguishable from the sibling blackboard_logout by the login/logout polarity, though it never names that counterpart 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 implied: an agent would call this when it has no valid session. However, the description never states the precondition (unauthenticated state) or points to blackboard_logout as the inverse operation, so the routing guidance is inferred rather than explicit.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond that by scoping the destruction precisely: session plus private profile are removed, while downloaded materials are preserved. It does not mention auth-state side effects or whether re-login is needed.

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 no filler; the primary effect is front-loaded and the exclusion follows immediately. Every clause carries information.

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

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

For a parameterless logout with no output schema and annotations that already cover safety and idempotency, the description supplies the one thing structured data cannot: the exact blast radius and what is deliberately left untouched. Nothing needed 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify on this dimension.

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

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

States a specific verb ('Elimina') and the exact resources affected (la sesión y el perfil privados de este MCP), which is unambiguous and distinct from the many read-oriented siblings. It also explicitly rules out the adjacent operation of deleting downloaded materials, preventing confusion with the download_* 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?

The tool's purpose implies its usage (ending a session), and the counterpart blackboard_login exists in the sibling list, but the description never states when to log out, whether it is required, or what happens to subsequent calls. Usage is only inferable.

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