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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds a genuine behavioral fact: score and feedback appear only at the Restricted tier, so output fields depend on access level. It does not say whose submission is returned (the authenticated student or an arbitrary one), which is significant given openWorldHint and the absence of a student parameter.

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

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

Two sentences, front-loaded with the core purpose and then the tier caveat. Every sentence earns its place; only the vague reference to 'the student' costs it a point.

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 shape need not be explained, and the tier note covers field availability. However, for a two-required-parameter tool with zero schema description coverage, the description should clarify the identity of the student and how to obtain the folder id, which it does not.

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 for both parameters and does not explicitly tie course_id or folder_id to their meaning. 'One assignment folder' hints that folder_id is the assignment folder, but course_id is never addressed and neither format nor sourcing is explained.

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

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

The description names a specific verb-plus-resource: reporting whether and when a student submitted to one assignment folder. That is materially more specific than the tool name alone and separates it from list_assignments or get_my_grades. It never names a sibling explicitly, so differentiation is indirect.

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 and no mention of alternatives such as list_assignments or compliance_status. The only hint is the phrase 'one assignment folder', which implies a per-assignment query, but the agent must infer that.

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, non-destructive, and openWorldHint=false, so the description is not burdened with the safety profile. It still adds real value by disclosing the key behavioral trait beyond annotations: the tool performs no Brightspace request, i.e. it reads local configuration only, and it names the policy dimensions returned.

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

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

Two sentences, zero filler. The reported fields are front-loaded in a compact enumeration, and the distinguishing constraint ('no Brightspace request') is placed last as a clean closing point.

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 the tool has no inputs, so the description does not need to document return structure or argument syntax. It still previews the returned policy dimensions, which is more than the minimum required for an agent to decide to call it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. Nothing in the description misrepresents the (empty) input contract.

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 (Show) and resource (Purdue policy settings in force), then enumerates exactly what is reported: AI data tier, enabled tools, courses with AI permission, request limits, and implementing policies. The closing note 'Makes no Brightspace request' separates it from every sibling, which all fetch Brightspace data.

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

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

Usage is implied rather than stated: an agent can infer this is the diagnostic/configuration view to consult instead of a Brightspace API call, but there is no explicit when-to-use or when-not-to-use clause. Given that it is the only non-Brightspace sibling, the lack of explicit routing guidance is a minor gap rather than a harmful one.

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 description correctly spends its words elsewhere: it discloses a non-obvious conditional that announcement bodies are withheld unless the course has AI permission, and flags the data as Purdue Sensitive. That is genuinely useful context an agent would not otherwise have. It does not explain truncation behavior or the meaning of 'recent', which keeps it out of the top band.

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 with the core purpose front-loaded, so there is little waste. However, 'Purdue Sensitive data.' is a dangling fragment with no predicate and no instruction about what the agent should do with that classification, which weakens an otherwise tight structure.

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?

Return values are covered by the output schema and the safety profile by annotations, so the definition is not dangerously incomplete. Still missing are the recency window, the effect and bounds of limit, and any statement about what the agent should do when bodies are omitted due to missing AI permission.

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

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

Schema description coverage is 0%, so the description carries the full burden and largely fails: 'one course' indirectly signals the required course_id, but the limit parameter (default 10) is never mentioned, and no maximum, pagination, or ordering semantics are given. 'Recent' is the only hint about result ordering or cutoff.

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 sentence names the specific resource and scope: announcements, restricted to one course, with a recency qualifier. No sibling tool overlaps (none of list_courses, get_course_outline, list_assignments cover announcements), so an agent can place it easily. It stops short of a clean verb+resource phrasing but the intent is unambiguous.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives for announcement retrieval. 'Recent' implies a recency filter but no window is defined, leaving the agent to guess whether older announcements are reachable at all.

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 two genuinely new pieces of context: that file contents are excluded, and that the output is classified 'Purdue Sensitive data', which signals handling expectations. It says nothing about pagination or size limits for large courses.

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

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

Two short sentences, front-loaded with the substantive scoping information. The trailing fragment 'Purdue Sensitive data.' is terse but carries real signal rather than 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?

An output schema exists, so return-format explanation is rightly omitted, and the annotations cover safety. The gap is the completely undocumented course_id and the absence of any guidance on sourcing that identifier, which for a single-param tool is the main thing an agent could get wrong.

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

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

There is one required parameter, course_id, and schema description coverage is 0%, so the schema offers no explanation of it. The description only implies the ID selects 'one course' and does not say where the value comes from (presumably list_courses) or whether it is the same ID used by sibling tools.

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 (module and topic titles) and scope (one course), which is enough to tell it apart from siblings like list_courses or list_assignments. It stops short of an explicit verb such as 'retrieve', but the noun phrase is unambiguous about what comes back.

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 a partial negative scope statement ('no file contents') that hints at what the tool will not return, but no alternative tool is named for fetching content. Nothing says when to prefer this over list_courses for navigating a course structure.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-derivable behavior: the Purdue Restricted data classification and the requirement that the AI client be authorized for Restricted data before any results are returned. It omits other behavior such as whether unreleased grades are hidden or how empty results present themselves.

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

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

Two short sentences, zero filler, with the resource scope stated first and the authorization constraint second. 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 one-parameter read tool with an output schema and full annotation coverage, this is close to sufficient: the data classification and authorization gate are the crucial non-obvious facts and both are present. The remaining gap is that the sole required parameter is wholly unexplained, which for a single-argument tool is a meaningful omission.

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 zero schema description coverage and no explanation in the description of its format, source, or validity constraints. The description does not mention the parameter at all, so an agent gets no help locating a valid course_id beyond guessing that list_courses supplies 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?

States a specific resource with narrowing qualifiers: "the student's own released grades in one course." That distinguishes it from list_assignments and assignment_submission_status, which cover assignment-level data rather than released final grades. The verb is only implicit (it never explicitly says "retrieves"), which keeps it just 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 context is implied through the word "released" (i.e., not all grades) and the explicit authorization precondition, but there is no explicit when-to-use/when-not guidance and no pointer to sibling tools such as list_courses for obtaining a course_id or assignment_submission_status for ungraded work.

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 read-only, idempotent, non-destructive safety profile, so the description's job is additive — and it delivers two real traits: instructions are returned conditionally, only for courses with AI permission, and the data is flagged as Purdue Sensitive. It does not mention pagination or behavior when the course_id is not one the student is enrolled in.

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

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

Two short sentences, front-loaded with what is returned, with no filler. The trailing 'Purdue Sensitive data' fragment is terse to the point of being cryptic but is not wasted space.

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 documentation is unnecessary and the definition is largely sufficient for a one-parameter read tool. However, the unexplained 'Purdue Sensitive data' marker and the unstated validity constraint on course_id leave an agent without guidance on handling restricted or invalid inputs.

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 has 0% schema description coverage, so the description must compensate. It does so only weakly, implying via 'one of the student's courses' that the ID must be a course the student belongs to, but never states the constraint explicitly or says how to obtain a valid ID.

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 (assignment folders) and enumerates the returned fields (names, due dates, points), scoped to 'one of the student's courses'. The listing verb is implicit rather than explicit, and differentiation from siblings like upcoming_due_dates is only inferable from the course scoping.

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 course-scoped framing implies when this is appropriate versus the cross-course upcoming_due_dates or assignment_submission_status, but no alternative is named and no when-not condition is given. Usage must be inferred rather than read.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description contributes one piece of non-structured context, the "Purdue Sensitive data" sensitivity marker, but omits meaningful behavior: that active_only defaults to true, meaning inactive enrollments are silently excluded.

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

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

Two short sentences with the scope and return payload front-loaded; no padding. The trailing "Purdue Sensitive data" fragment is terse but carries real information, so nothing penalizes structure.

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 described. However, with an undocumented boolean parameter and no indication of how course IDs relate to downstream sibling tools, an agent lacks the context to call it with intent rather than by default.

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

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

Schema description coverage is 0% for the single parameter, so the description carries the full burden and says nothing about active_only. It neither explains that the default of true hides inactive courses nor what false would return, leaving the only behavioral knob undocumented.

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

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

States a specific verb and resource ("List ... Brightspace course enrollments") and names the exact return content (course IDs), with a clear scope ("student's own"). It separates itself from siblings like list_assignments or get_course_outline by being the enrollment-level listing, though it never names those alternatives.

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

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

Usage is only implied: an agent can infer this is the place to get course IDs before calling per-course tools. There is no explicit when-to-use, no exclusion against get_course_outline, and no note on when active_only should be toggled.

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

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

Annotations only declare not-read-only, open-world, and non-destructive. The description adds substantive behavior: it launches an external browser page, the user must complete Duo approval manually, and the server never handles the password. It does not say whether the call blocks until completion, what happens if the user is already signed in, or that success should be confirmed via compliance_status.

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

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

Two short sentences, front-loaded with the action and followed by the security-relevant constraint. Every clause carries information an agent needs; nothing 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?

An output schema exists, so return values need no explanation, and the zero-parameter surface is simple. The one gap is the post-call workflow: nothing tells the agent how to verify that sign-in actually succeeded (the obvious route being the sibling compliance_status).

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies. No misleading parameter hints are given.

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

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

States a concrete verb and resource: opening Purdue's sign-in page in the user's browser. The Duo approval detail pins down exactly which authentication flow this is, so an agent can tell it apart from siblings like sign_out or compliance_status.

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

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

The phrase 'so they can sign in and approve Duo themselves' establishes the context in which to call it: an interactive browser sign-in the agent cannot perform on the user's behalf. There is no explicit exclusion or pointer to a sibling (e.g., compliance_status to verify the result afterward), which keeps it below 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 only declare readOnlyHint=false and destructiveHint=false; the description goes further by disclosing that cached data and stored tokens are wiped, which is the real behavioral consequence an agent needs to know. It stops short of saying whether re-authentication is required afterward or what happens if no session is active.

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

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

A single front-loaded sentence with no filler; the action comes first and the side effects follow. Nothing is wasted and nothing essential is buried.

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 values need not be explained, and a zero-parameter session tool has low complexity. The main remaining gap is the post-sign-out state (whether tokens must be re-obtained and whether other tools fail until sign_in is called).

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 for the description to supply. Baseline 4 applies.

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

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

The description gives a specific verb+resource ('End the Brightspace session') and adds the side effect of clearing cached data and stored tokens, so the agent knows exactly what this does. It is clearly the counterpart of the sibling sign_in, though it never names sign_in explicitly to reinforce the distinction.

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

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

Usage is only implied: signing out is self-evidently the action to take when ending a session. There is no explicit when-to-use or when-not-to-use statement, and no mention of prerequisites or consequences for subsequent tool calls.

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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds two pieces of real value beyond them: a hard 60-day cap and the 'Purdue Sensitive data' classification, which signals handling constraints. It does not say whether results merge assignments and calendar events or how the window boundaries are computed.

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

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

A single sentence that front-loads the resource and scope, with no padding. The stray backtick and line break around `days` slightly hurt readability but cost nothing substantive.

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 and rich annotations, the description does not need to explain return values, and it covers purpose, scope, cap, and sensitivity. The remaining gap is disambiguation from list_assignments and the undocumented default value, which an agent needs to call it correctly without inspecting the schema.

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 for `days`, and it does partially: it defines the parameter as a look-ahead window and states a max of 60. It omits the default of 14, the unit assumptions (inclusive/exclusive, timezone), and behavior when the value exceeds 60.

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 (calendar events and due dates) scoped to the student's active courses and a bounded time window, which is more than a restatement of the name. It stops short of distinguishing itself from list_assignments, which an agent could reasonably see as overlapping.

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 phrase 'upcoming ... for the next days days' suggests a forward-looking aggregate view, and the 60-day cap hints at the intended horizon. No alternative sibling is named, and there is no statement about when to prefer this over list_assignments or assignment_submission_status.

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