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 and idempotency profile is covered by structured data. The description adds the returned content inventory, which is useful, but says nothing about permissions, authentication, rate limits, or lookup failure behavior (e.g. what happens with an invalid 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?

Two sentences with no filler; the content inventory is front-loaded and the id/cmid note is appended. Slightly dense enumeration, but 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?

An output schema exists and annotations cover the safety profile, so the description need not explain return values or side effects. It is complete enough to call correctly, with the only real gap being the unexplained cmid alternative that the schema does not expose.

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 parameter carries no documentation, so the description has to compensate. It does add that the assignment id is 'preferred' and that a cmid is also accepted, but the schema exposes only one integer field named assignment_id, so the cmid mention is ambiguous rather than actionable and the actual format/range is never clarified.

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 (one assignment) and enumerates exactly what is returned: instructions, dates, submission requirements, status, grading, attachments. An agent can tell it is a single-item detail fetch. It never names or contrasts itself with nearby siblings such as upcoming_assignments or submission_status, so it stops short of a 5.

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

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

Usage is only implied: 'Everything about one assignment' suggests calling it when detail on a single assignment is needed, but there is no explicit when-to-use, when-not-to-use, or alternative routing versus the many sibling list tools. No prerequisites or context requirements are stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and idempotency profile is covered. The description adds the rich payload shape (items, feedback, dates), which is useful behavioral context beyond the annotations. However, it does not discuss permissions or any nuances of the data, so it sits at a solid 3 given annotation coverage.

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

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

A single, front-loaded sentence that packs the return shape without redundant clauses. It is appropriately sized for the tool and every element earns its place.

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

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

Given that an output schema exists, the description need not detail return values further; it focuses on what the tool is and its single input. The only small gap is explicit routing versus sibling grade tools, which is minor given the clear single-course scope.

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 only one parameter (course_id), and with 0% schema description coverage the description does not add syntax beyond 'for one course'. Per rule, 0-param baseline is 4; with one required simple identifier parameter and the description scoping the resource to one course, 4 is appropriate.

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

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

States a specific verb-and-resource (grade breakdown for one course) and enumerates what is returned: course total, percentage/letter, and every grade item with grade, range, weight, feedback and dates. This distinguishes it from siblings like current_grades and grade_history, which are not scoped to a single course detail 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 description implies usage via 'for one course' and requires course_id, but it does not explicitly say when to use this versus current_grades or grade_history. The single-course detail focus is implied, not stated as a 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description usefully adds what the result contains (changed modules, new announcements, notifications) and the accepted time formats, but says nothing about auth requirements, rate limits, or result limits beyond that.

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 sentences, front-loaded with the scope of changes, then the parameter format, then a plain-language restatement of the use case. The final sentence is somewhat redundant with the first two but functions as a memorable anchor, so little is wasted.

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

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

An output schema exists, so return-value shape needn't be explained, and the description covers scope and the main parameter format. The remaining gap is the unexplained course_id parameter, which an agent must guess at (per-course scoping vs. all courses).

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 here. It fully documents 'since' (ISO-8601, Unix timestamp, relative values like '24h'/'2d'/'yesterday'), which is valuable since the schema has no description for it. But 'course_id' is never mentioned, and the schema offers no help either — so half the parameter surface is undefined.

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

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

The description gives a specific verb+resource ('what changed in the student's courses') and enumerates the change categories covered: module settings/files/grades, new announcements, and Moodle notifications. That scope implicitly separates it from narrower siblings like recent_announcements, but the description never names or contrasts 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?

The closing line 'Answers "what changed since yesterday?"' situates the tool in a real use case, which is implied guidance. However, there is no explicit when-to-use vs. when-not, and no routing to alternatives such as recent_announcements or daily_briefing, which overlap on change/notification information.

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 adds genuinely useful return behavior: hidden gradebooks are still listed with access="hidden" rather than dropped, which an agent could not infer from the annotations.

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

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

Two tight sentences with no filler, and the primary behavior (return all visible course totals) is front-loaded before the hidden-gradebook 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?

An output schema exists, so return values needn't be explained, and annotations cover safety. The hidden-gradebook disclosure rounds it out, though the unexplained include_past parameter is a residual gap for an otherwise simple read 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?

There is a single parameter, include_past, with 0% schema description coverage, so the description must carry it. The description says nothing about the include_past flag or how past courses are handled, leaving the only parameter 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 gives a specific verb+resource (current course total) and a clear scope (every course the student can see). It implicitly distinguishes itself from single-course siblings like course_grade, but never names them explicitly, so it falls short of a 5.

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

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

The scope (all visible courses) implies the use case for a bulk listing versus a per-course lookup, but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings such as course_grade or grade_history. 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, non-destructive, open-world. The description adds the useful behavioral detail that `text` is display-ready while structured fields back it up, which tells the agent how to consume the output. It stops short of noting freshness/latency of the aggregation, but adds real value 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 compact sentences, front-loaded with the purpose and then the output shape. Slightly list-heavy but every enumerated item earns its place by defining scope. 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?

An output schema exists, so return-value detail is partly covered, and the description still adds the key split between human-readable `text` and structured fields. For a parameterless aggregator this is nearly complete; only freshness/latency of the aggregate is unstated.

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

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

Zero parameters, so the baseline is 4. Nothing to document, and the description correctly implies no inputs are needed for the briefing.

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 ('One-call academic briefing') and enumerates exactly what it aggregates: due today/tomorrow, coming up, overdue, events, announcements, and a priority order. The 'one-call' framing distinguishes it from the granular siblings like upcoming_assignments or overdue_assignments that each cover a slice.

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 'one-call' framing implies this is the aggregate entry point vs. the specialized siblings, and the enumerated content clarifies its scope. It doesn't explicitly say when NOT to use it or name an alternative (e.g., weekly_briefing for a longer horizon), so guidance is clear but not fully exhaustive.

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, so the safety profile is covered. The description adds a genuinely useful non-obvious trait: the module ids returned are course-module ids (cmid), preventing ID-space confusion. It stops short of noting payload size or pagination for what is clearly a heavy aggregate read.

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

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

The payload enumeration is front-loaded in one dense sentence, with the cmid caveat following as a short clarifying sentence. No wasted framing, though the parenthetical list is long and 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?

An output schema exists, so return-value details need not be restated, and the description is unusually thorough about contents plus the cmid caveat. However, it omits when to prefer this tool over the narrower material/assignment siblings and gives no guidance on the required course_id, leaving real gaps for a broad aggregate 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 the sole parameter course_id is never explained in the description. The cmid note hints that a different ID space exists for modules, but it does not tell the agent what a course_id is or where to obtain one.

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 ('Full view of one course') and enumerates exactly what is included: description, instructors, sections/modules, materials, and major activities. The scoping word 'one course' implicitly separates it from list_courses, but no sibling is named explicitly, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is the tool to reach for when it needs complete detail on a single course, versus search_course_materials or get_material for narrower lookups. There is no explicit when-to-use, when-not, or named alternative.

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, open-world, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: content is returned conditionally for text-bearing items, PDFs require an optional 'pdf extra' to be installed, and folder files are addressed differently — all things the agent cannot infer from 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?

Purpose and conditional return behavior are front-loaded in the first sentence, with parameter format details following. It is dense but free of filler; the parenthetical type list is long yet each element is load-bearing information about what qualifies as text-bearing.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. The description supplies the remaining essentials — what is fetched, when content accompanies metadata, and the accepted ID forms — though it says nothing about error behavior for invalid IDs or permission requirements, which would complete the picture for an open-world read 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 carry the full burden, and it does: it defines material_id as coming from search_course_materials, accepts a course-module id (cmid), and gives the distinct '<cmid>/<n>' form for folder files. This fully compensates for the undocumented schema field.

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 ('Metadata for one material') and adds a precise scope condition ('plus its content when it is text-bearing') with a concrete list of supported material types. It only indirectly differentiates itself from siblings by naming search_course_materials as the source of material_id, rather than explicitly contrasting the two 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?

Usage is implied: the agent learns that material_id comes from search_course_materials or a cmid, which hints at a search-then-fetch flow, and that content is only returned for text-bearing types. However, there is no explicit when-to-use statement, no exclusions, and no guidance on alternatives if the caller already has a folder path.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real value beyond them: it discloses that no true history service exists, that values are each item's CURRENT grade paired with graded/submitted dates, and that ordering is newest-first. This manages expectations about data fidelity, which the annotations cannot.

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 purpose and the key caveat are front-loaded, and the parenthetical detail (newest first) is efficiently placed. The trailing 'and says so explicitly' is slightly redundant phrasing but not wasted length overall.

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 an output schema present, return-value structure need not be described, and the annotations cover safety. The description supplies the crucial limitation and ordering semantics; only an explicit sibling-selection rule 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?

There is a single parameter (course_id) with 0% schema description coverage, so the description carries the burden. It only implies the parameter's meaning via 'for a course' and adds no format, type, or source detail, which is minimal but not absent.

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 scope: 'what Nexus exposes about grade changes over time for a course,' which is clearly distinguishable from a point-in-time snapshot. It does not, however, explicitly name the confusable siblings (current_grades, course_grade), 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?

Usage is only implied: the emphasis on 'over time' and the caveat about Moodle lacking a grade-history service suggest this is the tool for historical/temporal questions. There is no explicit when-to-use statement, no when-not-to-use, and no direct routing to current_grades or course_grade.

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 adds real behavioral context: classification is computed from Moodle start/end dates, and non-academic enrolments lack term codes, which explains the filtering semantics.

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

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

Front-loads the core purpose, then the classification detail, then the academic_only caveat; every sentence carries information. Slightly awkward formatting with the indented block and quoted default, but no wasted content.

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 both optional parameters, their defaults, and the id handoff to other tools; with an output schema present it need not spell out return values. A brief note on ordering or whether 'all' includes hidden vs past would make it fully complete.

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

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

Schema coverage is 0% and no enums are declared, so the description carries the full burden. It documents all five classification values with the default ('inprogress') and the exact effect of academic_only=true, which is a substantial addition over the bare boolean/string schema.

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

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

States a specific verb (List) and resource (the student's Nexus courses) and enumerates exactly what each entry contains (id, name, short name, teacher, term). This lets an agent distinguish it from the singular get_course sibling without opening the schema.

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

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

Explains when the classification modes apply (derived from Moodle start/end dates, default 'inprogress') and what academic_only=true filters out (trainings, campus resources with no term code), plus the downstream 'use id with other tools' handoff. It stops short of explicitly naming competing siblings like get_course or course_updates.

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 that it exposes token capabilities and the canonical timezone for dates, which is mildly useful behavioral context, but it does not mention auth requirements, caching, or freshness.

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 listing the four returned facts, front-loaded with the most important one (who is signed in) and free of 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 an output schema present, the description does not need to explain return values, so its main gap is the absence of any usage routing or prerequisite guidance. As a zero-parameter, read-only status probe the definition is otherwise sufficient for correct invocation.

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

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

The tool takes zero parameters, so there are no semantics for the description to add; the baseline for parameterless tools applies. Nothing in the text misleads about inputs.

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

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

The description enumerates exactly what the tool reports: signed-in identity, Nexus/Moodle release, the timezone used for dates, and the token's capability set. That distinguishes it from every sibling, which all deal with courses, assignments, grades, or content rather than system/account status, though it never states a verb like 'Returns' or 'Reports'.

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

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

Usage is only implied: an agent can infer it should call this to resolve identity, date timezone, or permissions before other operations. There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives among the 17 sibling tools.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world traits, so the description earns credit for extra behavior: that due dates are extension-adjusted, that only current courses are scanned by default, and that items are filtered by age. It omits auth/permission or rate-limit context, but for a scoped read tool this is substantive added value.

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 sentences, roughly 60 words, with the core definition front-loaded and no filler. Every clause (extension adjustment, course scoping, age filter, cut-off flag) carries distinct 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?

An output schema exists, so return values need not be enumerated, yet the description still explains the key semantic field can_still_submit. Combined with both parameters being covered, an agent has everything needed to call this 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%, so the description must carry the parameter burden and largely does: course_id scopes the scan to one course instead of the default current-course set, and max_age_days is explained as an age cut-off. It doesn't restate the 120-day default or clarify units beyond 'days', keeping it from a 5.

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 precise resource and predicate: assignments whose extension-adjusted due date has passed AND that Moodle reports as not submitted. That two-part condition cleanly distinguishes it from upcoming_assignments and submission_status without needing to name them.

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

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

Gives clear selection context: default scope is current courses, and items older than max_age_days are ignored. It stops short of explicitly naming alternatives (e.g. upcoming_assignments) or stating when-not to use it, but the contrast is strongly implied by the 'passed due date' framing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld. The description adds meaningful behavioral detail beyond those flags: the search scope (Announcements/News forum of each current course), ordering (newest first), and the include_all_forums expansion. Lacks any note on pagination or volume limits, keeping it below 5.

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

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

Two tightly packed sentences with the core scope front-loaded: time window first, then expansion behavior. Slightly dense but every clause adds information; minimal 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?

Covers the primary use case, default scope, and the key expansion flag across 3 optional parameters, and an output schema exists so return values need not be described. The omission of `course_id` semantics is the main gap for an otherwise complete definition.

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 explains `days` as the time window, the implicit course scope, and `include_all_forums` as a scope expander. `course_id` is never mentioned, so one parameter remains unexplained, preventing a 5.

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 (announcements from instructors) with explicit scope: last `days` days, current courses' Announcements/News forum. Distinguishes itself from content-oriented siblings like search_course_materials by naming the exact forum and time window.

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?

Describes the default scope and the include_all_forums=true alternative, giving an implicit when-to-use for both modes. Does not name other sibling tools (e.g., search_course_materials) as alternatives for broader searches, so it falls short of explicit when-not guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine extra context with the negative behavior "Nothing is downloaded by this call," which clarifies that matching files are not fetched. Pagination/limit behavior is left unstated, keeping it from a 5.

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

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

Three sentences, each earning its place: purpose/scope first, return fields second, the "nothing is downloaded" caveat last. Zero waste and front-loaded with the essential 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?

With an output schema present, the return-value enumeration is a bonus rather than a necessity, and the annotations cover safety. The description routes the agent to get_material and states scope, leaving only the limit parameter's behavior undocumented.

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 load. It meaningfully explains query semantics ("by title, filename, description or section name") and course_id scoping ("across current courses (or one course)"), but the limit parameter is never addressed, so it compensates for two of three parameters.

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

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

The description opens with a specific verb+resource ("Search course materials"), enumerates what counts as a material (PDFs, pages, books, links, folders, lecture notes), and states the searchable fields. It also distinguishes itself from the sibling get_material by noting it returns a material id for that tool, so an agent can separate discovery from retrieval.

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 clear scope ("across current courses (or one course)") and a routing hint toward get_material via the returned id, implying a search-then-fetch workflow. It stops short of an explicit when-to-use/when-not statement or naming any alternative search tool, so it earns a solid 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing caching freshness via freshness.cached and noting that grade/feedback is only present 'when released' — information an agent cannot get from the annotations. It omits rate limits or error behavior.

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

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

Two sentences, no redundancy, and the core purpose plus the status enumeration are front-loaded before the caching caveat. 'straight from Moodle' is mild flavor text but also signals the authoritative source, so it mostly 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?

With an output schema present, return-value structure need not be described, and the description still covers the meaningful return states and the freshness caveat. For a single-parameter read-only lookup this is nearly complete, though edge cases (assignment not found, missing assignment) are unaddressed.

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

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

There is a single required parameter, assignment_id, whose schema has 0% description coverage, so the description must compensate, and it only implies scope via 'for one assignment.' That is enough for a self-describing integer ID but adds no format, source, or constraint detail.

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 (submission status for one assignment) and enumerates the exact possible return states (not_started, draft, submitted, graded, overdue), which lets an agent distinguish it from aggregate siblings like current_grades or overdue_assignments. It stops short of explicitly naming a sibling it replaces, so it's clear but not fully differentiated.

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 usage instruction is 'Check freshness.cached before calling the value real-time,' which is a data-staleness caveat rather than when-to-use guidance. There is no statement of when this tool is preferable to assignment_details, current_grades, or overdue_assignments, and no exclusions or prerequisites.

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/openWorld/destructive, so the burden is lower. The description adds the ordering guarantee, timezone handling ('student's timezone'), and the status enumeration, which are useful beyond annotations. It does not mention pagination or result caps, a minor gap given the output schema exists.

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

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

Front-loaded with the core verb and the practical use case ('what's due this week?'), followed by supporting details. Every sentence earns its place; 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?

Output schema exists, so return-shape explanation is unnecessary. Annotations cover safety. The description is complete for an agent to select and invoke the tool, with only course_id and pagination as minor omissions.

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

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

Schema coverage is 0%, so the description must compensate. It explains `days` (window), `include_submitted` (hide finished work), and implies `course_id` scoping, though course_id is not explicitly documented. Three params with two well-covered and one implied is above the 3 baseline.

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

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

States a specific verb+resource (assignments due within N days), the ordering (by due date), and the payload (submission status, points, URL). It also positions itself against siblings with 'the one call to make for what's due this week,' distinguishing it from upcoming_events and overdue_assignments.

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

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

Explicitly names the intent ('what's due this week?') and the alternative behavior via include_submitted=false. The behavioral toggle is spelled out with the condition that selects 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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds useful content detail – what fields each event includes and that results are chronological – but does not disclose pagination, limits on the number of events, or behavior when course_id is null vs set.

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 core purpose (calendar events for the next days, chronological). The trailing enumeration of event types is somewhat long but each item earns its place by clarifying scope. 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?

The description adequately conveys what is returned, and an output schema exists so return-value structure needn't be explained. However, with 0% schema coverage, the complete absence of `course_id` semantics leaves a real gap for such a simple two-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%, so the description must compensate for parameter meaning. It references `days` implicitly via 'next `days` days' but never explains the `course_id` parameter at all, nor clarifies whether omitting it returns all courses. Two parameters are effectively undocumented beyond their names.

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 (retrieves calendar events) with a clear time scope ('next `days` days') and enumerates exactly which event types are included (assignment due dates, quiz open/close, course events, personal/site events). It is easily distinguishable from siblings like upcoming_assignments (which is assignment-only) or daily_briefing.

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

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

Usage is implied by the description – this returns a chronological calendar of upcoming events – but there is no explicit when-to-use vs alternatives guidance. It doesn't tell the agent, for example, when to prefer this over upcoming_assignments or workload_analysis.

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. The description adds useful content context (it merges assignments, deadlines, and overdue items in one view), but says nothing about ordering, pagination, or auth needs, so it adds only modest value 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?

A single sentence, front-loaded with the scope and then the contents; nothing is redundant. It is efficient, though the telegraphic style leaves a couple of concepts underspecified.

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

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

Because an output schema exists, return values need not be explained, and the safety annotations cover the risk profile. What is missing is any routing against the many sibling briefing/assignment tools and any explanation of the days parameter, which matters for a tool with a configurable window.

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 one parameter (days, default 7) with 0% description coverage, and the description hardcodes 'the next 7 days' without acknowledging that the window is configurable. This leaves the parameter undocumented and arguably obscures its purpose rather than explaining it.

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

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

The description names the resource and its scope precisely: the next 7 days grouped by course, covering assignments (with status), calendar deadlines, and overdue items. An agent can tell what it returns without opening the schema. It never differentiates itself from the obvious sibling daily_briefing, 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?

There is no explicit when-to-use statement or named alternative, but the 7-day window implies this is the weekly counterpart to daily_briefing and broader than upcoming_assignments. Usage is inferable from scope rather than stated, and no exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioural context beyond them: what sources are synthesised and that every item carries a HIGH/MEDIUM/LOW ranking with a stated rationale, which tells the agent what kind of judgement output 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 sentences, no filler, and the core output (a prioritised to-do list) is front-loaded before the source list. 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?

Complexity is low (no parameters) and an output schema exists, so return values need not be spelled out; annotations cover the safety profile. The description adequately covers inputs and output shape, with the only real gap being guidance on when this beats the overlapping briefing tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; the description does not need to compensate for any 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 artifact (a prioritised to-do list) and enumerates the inputs that feed it — overdue work, due dates, submission status, calendar deadlines, announcements — plus the ranking explanation. That is enough to distinguish it from the narrow siblings like overdue_assignments or upcoming_assignments, though it does not explicitly contrast itself with the similarly aggregating daily_briefing/weekly_briefing.

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 at all. With many overlapping siblings (daily_briefing, weekly_briefing, workload_analysis, overdue_assignments), the agent is left to infer whether this tool supersedes or complements them; nothing in the text routes the choice.

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 adds genuinely valuable context beyond that: it separates ground-truth Moodle `facts` (counts, points, quizzes, overdue) from `estimates` that are nexus-mcp heuristics and explicitly not instructor-provided, which materially changes how an agent should present and trust the numbers.

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 clauses with the core subject front-loaded and zero filler. The backtick-quoted `days` reference is a nice tie-in to the schema, though the sentence is slightly awkward to parse on first read.

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 an output schema present, the description needn't enumerate return fields, yet it helpfully characterizes the two payload sections anyway. Annotations cover the safety behavior. The remaining gap is routing guidance against the many sibling tools, which is not covered.

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

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

Schema description coverage is 0%, so the description must carry the load for the single `days` parameter. It does communicate the forward-looking window ('for the next `days` days'), but it never states the default of 7 or the expected range/format, leaving partial ambiguity.

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 (workload over the next `days` days) and breaks it into two well-named parts, `facts` and `estimates`, which tells an agent exactly what it gets back. It does not, however, distinguish this tool from close siblings like `what_should_i_do_next` or `upcoming_assignments`, which also surface near-term obligations.

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 exclusions, and no named alternative. The forward-looking framing implies a planning use case, but the agent must infer that on its own rather than being told when this beats `daily_briefing` or `upcoming_assignments`.

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