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

Annotations already establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that the output is an ICS artifact intended for import and that empty input defaults to all active classes, but it never defines the 'upcoming' time window or whether the result is file content, a URL, or a download.

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

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

Three short sentences, front-loaded with the artifact produced and followed by scoping and a usage trigger; nothing is padded. The quoted user phrasing is slightly verbose but functions as a useful selection cue.

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 comes back, and it leaves ambiguous whether the ICS is returned as text, a file, or a link. The undefined 'upcoming' horizon is a second gap for a tool whose entire value is the date range it 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 coverage is 100% and the single parameter is already documented, including a pointer to get_my_courses. The description only restates the empty-means-all-active-classes default, which the schema already says, 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?

The description names a specific verb (build/export), resource (upcoming due dates), and output artifact (ICS calendar file), which is far more informative than the title alone. It doesn't explicitly contrast itself with the close sibling get_upcoming_due_dates, so an agent must infer the difference from the 'calendar file' framing.

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

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

It gives a concrete trigger via the quoted user request ('Can you give me my due dates as a calendar file?') and explains the scope decision for the optional parameter (limit by course_ids or leave empty for all active classes). It stops short of naming an alternative like get_upcoming_due_dates for when the user just wants a list rather than a file.

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 and open-world access, so the description's job is lighter. It adds genuinely useful behavior: the default scope is all active classes, results include a direct Classroom link, and no filter means every 'recent' announcement. The vague boundary of 'recent' is left undefined.

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 what the tool returns, then scoping, then the user-intent examples. The scoping sentence partially duplicates the schema but the example queries earn their place; minor redundancy keeps it below 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?

With no output schema, the description carries return-value burden and does describe the link-carrying shape, though it omits other announcement fields, ordering, and any result cap. Combined with annotations, this is enough for an agent to call it correctly, with minor unknowns.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema, including the get_my_courses lookup hint. The description restates the same filtering intent without adding format, syntax, or interaction details, 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 the resource precisely ('Recent announcements') and even the return shape ('each with a link to open it in Classroom'). It is distinguishable by resource from siblings such as get_course_materials and get_whats_new, though it never explicitly contrasts with get_whats_new, which could plausibly overlap.

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 concrete trigger phrasing ('Did my teacher post anything new?') and explains the scoping choice: pass course_ids or since_days, or leave empty for all active classes. It lacks an explicit when-not-to-use or a named alternative, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds value by disclosing the returned payload (description body, attachments, due date, points, personal status), which matters since there is no output schema. It does not cover error behavior, permissions, or 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?

Three sentences, front-loaded with the capability, then the payload, then the invocation and usage triggers. No sentence is filler; the usage examples do real routing work.

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

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

For a two-parameter read tool with full schema coverage and annotations covering the safety profile, the description supplies the remaining pieces an agent needs: what is returned, how to call it, and when it applies. Nothing material is missing.

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

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

Schema coverage is 100% and the schema already documents both parameters, including pointers to get_my_courses and get_assignments for lookup. The description only restates 'Pass the course ID and the assignment ID', adding no format or type guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Everything about one assignment') and enumerates exactly what is returned: description text, attachments/links, due date, points, and submission status. This is clearly distinguishable from sibling list tools like get_assignments or get_upcoming_due_dates.

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 concrete triggering user questions ('What does this assignment ask for?', 'What do I need to turn in?') and scopes usage to 'one specific assignment', which implicitly separates it from the list tools. It never names an alternative sibling explicitly or states a when-not condition, so it falls short of a 5.

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

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

The annotations already establish that this is a read-only, open-world operation, so the lower bar applies. The description adds useful return context (due dates, status, Classroom links, points), but it does not cover pagination, ordering, permissions, or the full 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 tightly written sentences. The first front-loads what the tool returns, and the second gives the primary usage scenario without unnecessary repetition.

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

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

For a simple one-parameter read tool with annotations and no output schema, the description is largely complete: it states scope, return fields, and a typical user request. Minor gaps remain around sibling differentiation and response ordering/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?

The single course_id parameter is fully documented in the schema, including how to obtain it via get_my_courses. The description reinforces that the tool operates on one class but adds no syntax or formatting details beyond the schema.

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

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

The description clearly specifies the resource (assignments for one class) and the returned fields (due dates, status, links, points). It distinguishes the scope as single-class rather than all-class, though it does not explicitly name overlapping siblings such as get_todo or get_upcoming_due_dates.

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 provides a concrete use case: when the user asks what is due in a particular class or wants every assignment and its points for one class. It does not explicitly state when to prefer get_todo, get_upcoming_due_dates, or get_missing_assignments instead, but the single-class framing gives clear context.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds the otherwise-unknown return shape — materials grouped by topic with a Drive link for each attached file. With no output schema present, that return-format disclosure is the main value add, though pagination and coverage limits are unmentioned.

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?

Lead sentence delivers the resource and return shape up front, and the second sentence is a single purpose clause with example queries. Slightly example-heavy for a one-parameter tool, but no sentence is 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 simple read tool with one fully documented parameter and annotations covering safety, the description supplies what's missing: what the result looks like (topic grouping plus per-file Drive links). Nothing critical is absent, though an agent gets no sense of result size or whether all topics always appear.

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?

Only one parameter and the schema already documents it fully, including the pointer to get_my_courses for obtaining the ID. The description adds nothing about course_id, so the schema does all the work and the baseline of 3 applies.

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

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

States a specific resource (posted class materials for one class), its organization (grouped by topic), and its payload (Drive link per attached file). That distinguishes it cleanly from sibling tools such as get_assignments and get_announcements, which return different artifacts from the same course.

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 three concrete trigger phrasings ('What materials did my teacher post?', 'What did we cover in unit 3?', 'readings, slides and handouts'), which makes routing from natural user language straightforward. It does not explicitly exclude neighbors like get_announcements, so the boundary is inferred rather than 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 and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: the result set is restricted to past-due and unsubmitted items, and the empty-parameter default resolves to 'all active classes'. It stops short of describing result fields or ordering, which keeps it at 4.

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

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

Three short sentences, front-loaded with what the tool returns, then the scoping parameter, then invocation cues. Nothing is redundant or padded.

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

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

For a single optional parameter with full schema coverage and annotations, this covers everything an agent needs to decide and call. The only minor gap is that no return shape is described and no output schema exists, so the agent knows less about what fields come back.

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

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

Schema coverage is 100%, and the schema already documents that course_ids is optional and that empty means all active classes, plus the pointer to get_my_courses. The description restates that default without adding new semantics, so the baseline 3 is appropriate.

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

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

States a specific resource and a precise filter: past-due work that has not been submitted. It is clearly distinguishable from sibling tools like get_todo, get_upcoming_due_dates, and get_assignments based on the 'overdue' framing 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?

Gives concrete user phrasings ('What's overdue?', 'What am I behind on?') plus the scoping rule (pass course_ids or leave empty for all active classes). No explicit 'when not to use' or named alternative tool, which keeps it just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one real behavioral detail beyond that: the list is limited to 'active' classes, implying archived/inactive courses are excluded. It says nothing about ordering, pagination, or how 'active' is determined, so the added context is modest.

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 purpose is front-loaded before the usage hint. Every clause carries information an agent would otherwise have to infer.

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 tool with readOnly/openWorld annotations, this is sufficient: the description covers what is returned (courses plus IDs), the scope (active), and the reason to call it. No output schema exists, but the return content is characterized well enough 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 is no parameter semantics to explain and the baseline of 4 applies. The phrase 'with their IDs' usefully describes the payload shape rather than any input.

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') plus the exact resource ('the student's active Google Classroom classes') and the key returned field ('their IDs'). This is clearly separable from siblings like get_assignments, get_my_grades, or get_course_materials, which operate on content within courses rather than the course roster itself.

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

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

Gives a concrete trigger ('What classes am I in?') and a downstream reason to call it ('needs a course ID to pass to another tool'), which is exactly the routing signal an agent needs. It stops short of naming an explicit alternative or a when-not condition, so it lands just below the top band.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's job is to add context beyond safety. It does that well: it discloses that there is no overall grade, that the number is an aggregation of graded work only, and that weighting applies only when grading categories with weights exist. It omits return shape and any rate-limit or pagination behavior, 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?

Front-loaded with the core purpose, then the aggregation caveat, then parameter guidance, then trigger examples. Every sentence carries information; the only mild cost is length across four sentences, but nothing is redundant with the schema beyond the empty-parameter restatement.

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 must convey what comes back, and it does: per-class grades, teacher comments, and a weighted percent when applicable. Combined with a single optional parameter and clear annotations, an agent has enough to call it correctly; only the exact response structure and error/edge behavior are unstated.

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

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

Schema description coverage is 100% and the schema already says 'Classroom course IDs to check. Leave empty for all active classes.' The description restates the same empty-means-all-active-classes behavior without adding format, limits, or validation details, 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 resource and scope: 'Grades on returned work for each class, with the comment the teacher left.' It also explains the derived semantics (no overall grade in Classroom, so it sums graded work and computes a weighted percent when categories have weights), which distinguishes it from siblings like get_assignments or get_assignment_details.

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

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

Gives explicit trigger phrasing ('How am I doing in my classes?', 'What grades have I gotten back?') and explains the parameter branch: pass course_ids to limit, leave empty for all active classes. It does not say when to prefer a sibling such as get_target_grade or get_assignment_details instead, so it stops short of a 5.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior: it aggregates earned and remaining points and reports the points still needed, with scoping via course_ids. It does not explain edge cases like impossible targets or output structure.

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 front-loaded with the core purpose and then adds only useful clarification about target_percent, course scoping, and example user intents. There is no redundant or wasted text.

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

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

For a two-parameter read-only tool with no output schema, the description is complete enough: it explains what is computed, how target_percent and course_ids affect scope, and what the user receives. No critical calling information is missing.

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

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

Schema coverage is 100%, so both parameters are already documented in the input schema. The description restates target_percent’s 0–100 range and course_ids’ empty-means-all-active behavior but adds no syntax or format detail beyond the schema.

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

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

The description states a specific computation: points needed on remaining work to reach a target percent in each class. It clearly identifies the resource and outcome, making it distinguishable from siblings like get_my_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?

It gives concrete user-question examples such as “What do I need to score to get a 90?” and explains that course_ids limits scope while empty means all active classes. It lacks an explicit when-not or named alternative such as get_my_grades for current grades.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not carry the safety burden. It does add useful context beyond them: the result includes an openable Classroom link per item, and an empty filter means all active classes rather than none. Nothing about pagination, result caps, or permissions is disclosed, so the description is helpful but not rich.

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

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

Three sentences: what is returned first, then how to scope it, then example user phrasings. That front-loading is good. The scoping sentence duplicates the schema description, so it earns slightly less than a full 5, but nothing is padded.

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

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

For a single-parameter read tool with annotations and no output schema, the description covers scope, default behavior, and return payload (links), which is enough to call it correctly. The remaining gap is that it never clarifies how it relates to get_missing_assignments or get_assignments, but that is a minor omission for a tool this simple.

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

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

Schema coverage is 100%: course_ids is documented as 'Classroom course IDs to check. Leave empty for all active classes', and the item description points to get_my_courses. The description's 'Pass course_ids to limit it, or leave empty for all active classes' restates that rather than adding format guidance or semantics, so the baseline of 3 applies.

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

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

The description states a specific verb-plus-resource ('everything assigned that the student has not turned in yet') and mentions the returned link, so an agent can tell what the tool does. It does not distinguish this tool from the close sibling get_missing_assignments, whose scope ('not turned in') sounds nearly identical, so the tool's purpose is 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 description gives concrete triggers by quoting the user questions it answers ('What do I still have to do?', 'What's left to turn in across all my classes?') and explains when to pass course_ids and when to leave it empty. It names no alternatives or exclusions, so the agent is left to infer on its own when get_missing_assignments or get_upcoming_due_dates would be better.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely new behavioral facts: results are scoped to not-turned-in work, ordered soonest-first, and both parameters can be omitted with a defined default (all active classes, all future dates). Nothing contradicts the annotations. It stops short of noting any result cap or volume expectation for a cross-class query.

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

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

Three short sentences: what it returns and in what order, then how to narrow, then when to reach for it. The most useful information is front-loaded and no sentence is redundant 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?

With only two optional parameters, full schema coverage, and no output schema to compensate for, the description covers what the tool returns, its ordering, its defaults, and its trigger. It is slightly thin on how the result set is bounded for 'all classes', but that is a minor omission for a simple read.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'leave empty' defaults and the pointer to get_my_courses. The description restates the same narrow-or-omit behavior rather than adding syntax, format, or interaction detail (e.g., how the two filters combine), 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 resource and filter: work that is due soon and not turned in, returned soonest first. That is concrete enough to predict the payload, but it never names or contrasts the closest siblings (get_todo, get_missing_assignments, get_assignments), so an agent must infer which of these four overlapping list tools 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?

Gives a concrete when-to-use trigger in the form of user questions ('What's due this week across all my classes?', 'What's coming up?'), which is more actionable than generic 'use for due dates' phrasing. It lacks any when-not guidance or explicit routing away from get_missing_assignments/get_todo, which is the main gap given how similar the siblings are.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond that: it is an aggregating digest, it includes teacher comments on graded work, and it spans both backward-looking (overdue) and forward-looking (due next) windows — useful framing for interpreting 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?

Three sentences, front-loaded with the core purpose, then parameter guidance, then triggering examples. No filler and the most decision-relevant information comes first.

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

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

With no output schema, the description carries the burden of describing returns, and it does so at a useful level by naming the four result categories and the inclusion of teacher comments. It stops short of describing result shape or ordering, but for a read-only digest this is close to 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 100%, and the schema already documents each parameter including defaults. The description restates the same semantics ('Pass course_ids to limit it, since_days for how far back, days_ahead for how far ahead') without adding format details, valid ranges, or edge-case behavior beyond the schema. Baseline 3 applies.

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

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

The description states a specific verb+resource ('one catch up digest for every class') and enumerates the four content categories (announcements, newly graded work with teacher comments, overdue work, due next). The word 'digest' plus the enumeration clearly distinguishes it from the single-purpose siblings like get_announcements or get_missing_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?

It gives concrete triggering user utterances ('What's new since yesterday?', 'What changed in my classes?'), which is strong positive guidance. It does not explicitly name when to prefer a narrower sibling tool (e.g. get_announcements for announcements only), so the routing boundary is inferred rather than stated.

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