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

No annotations are provided, so the description carries the full behavioral burden. It reveals the categories of data returned, but says nothing about authentication (notable given siblings like interactive_login and set_session_cookie), rate limits, or whether the caller must be the student or a teacher. For a zero-annotation tool this is a real gap.

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

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

A single efficient sentence with the verb and the three checked aspects front-loaded and no filler. It is appropriately sized, though its brevity leaves the transparency gaps noted elsewhere.

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

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

With one simple parameter and no output schema, the description minimally suffices to know what the tool returns conceptually. But with no annotations, it omits auth requirements and caller-role expectations that an agent would need before calling it.

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

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

Schema description coverage is 100%, so the single url parameter and its Moodle format example are already fully documented in the schema. The description adds no syntax or format detail beyond that, which makes the baseline 3 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?

The description names a specific verb (Check) and enumerates the resources inspected: submission status, grading status, and feedback for a specific assignment. This is far more concrete than a tautology and clearly distinct from siblings like list_modules or get_deadlines. It does not, however, explicitly contrast itself with any sibling tool.

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

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

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The use case can be inferred from the purpose, but nothing in the text guides tool selection among the nine siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It doesn't say whether this is a read-only check, whether 'checking' mutates a seen/unread state, whether it requires authentication, or what the result contains. 'Check for new' implies read but leaves mutation semantics ambiguous.

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

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

A single, front-loaded sentence with no filler. It is appropriately sized, though it wastes the opportunity to disambiguate against siblings in the same breath.

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

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

For a tool with no annotations and no output schema, the description should clarify return content (e.g., new materials vs. announcements) and its relationship to get_announcements. Instead it leaves the module-vs-course scope mismatch unresolved, so the agent cannot be confident about what it will get 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 single courseId parameter is fully documented in the schema, so the baseline is 3. The description adds no syntax or format detail, and its mention of 'module' conflicts with the course-level parameter, which adds mild confusion rather than clarity.

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 clear verb+resource ('check' + 'new materials or announcements in a module'), so the agent knows the general intent. However, it does not differentiate from the sibling get_announcements, and it says 'a specific module' while the only parameter is courseId, blurring the scope of what is actually checked.

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

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

No when-to-use guidance is given. With siblings like get_announcements, sync_module, and list_modules present, the agent has no stated criteria for choosing this tool over those, and no prerequisites (auth, session) are mentioned.

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?

No annotations are provided, so the description carries the full burden and falls short. It never states that the tool writes to local disk, whether an existing file is overwritten, what authentication is required, or what happens for non-file URLs. Only the schema hints at the destination directory.

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 zero filler; the verb, resource, examples, and required input all appear immediately.

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 annotations and no output schema, the description should explain the tool's side effects and result (e.g., returns a saved file path) and any auth or overwrite behavior. None of that is present, leaving significant gaps for a write-to-disk operation.

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 url and outputDir are already documented in the schema, making 3 the baseline. The description reinforces that url is a Moodle resource URL and clarifies the file types expected, but adds no format or syntax 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?

States a specific verb (Download) and resource (file from Courseweb) and clarifies scope with examples (PDFs, lab sheets) plus the required input (resource URL). It does not, however, distinguish itself from a plausible sibling like scrape_page, which could also fetch content from Courseweb.

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

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

No guidance on when to prefer this over scrape_page, nor any prerequisites such as needing an authenticated session first (siblings set_session_cookie and interactive_login suggest auth is a real concern). Usage is only implied by the phrase 'given its resource URL'.

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?

With no annotations, the description carries the full behavioral burden, and 'Get' is the only signal that this is a read. It says nothing about authentication needs, caching, pagination, or whether announcements are site-wide versus per-course, so an agent cannot predict behavior beyond the trivial read implication.

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 or repetition. It is efficient, though it is so terse that it omits useful context rather than being verbose.

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 no output schema, the description is minimally adequate but omits what an announcement actually contains (title, date, body) and what 'general' scopes to. With no annotations to fall back on, a bit more behavioral context would be warranted.

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 per the rubric this is a baseline 4. The description has no parameters to explain and does not need to add anything here.

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

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

States a clear verb ('Get') and resource ('general site announcements from Courseweb'), which is enough to distinguish it from siblings like get_deadlines and list_modules. It does not, however, explicitly contrast itself with any sibling or clarify the scope of 'general' (site-wide vs. course-specific).

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., whether a session/login is required), and no alternative named. The agent is left to infer that this is simply the announcements fetcher.

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?

No annotations are provided, so the description carries the entire behavioral burden. It does not say whether a Courseweb session/cookie is required (siblings set_session_cookie and interactive_login suggest authentication is a real concern), how far ahead 'upcoming' reaches, whether results span all courses, or how they are ordered, so an agent cannot predict the call's 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?

A single front-loaded sentence that names the action, the data, and the source with no filler. It is efficient, though the brevity is partly under-specification rather than tightness.

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 parameters, no output schema, and no annotations, the description is the sole carrier of context. It covers what is returned at a high level but leaves the time window of 'upcoming', authentication requirements, and result shape unspecified, which is adequate but not complete for a data-fetching 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?

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

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

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

States a specific verb (Fetch) plus a clear resource (upcoming assignment deadlines and events) and even names the source system, Courseweb. It is distinguishable from siblings like get_announcements or check_assignment_status by the 'deadlines and events' framing, but it never explicitly addresses those near-neighbors, 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 only usage signal is the word 'upcoming', which implies a forward-looking planning use case. There is no statement of when to prefer this over get_announcements or check_assignment_status, no prerequisites, and no exclusions.

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

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

With no annotations, the description carries the full burden. It does disclose a real behavioral trait beyond the empty schema: this is interactive, opens a browser, and requires manual user action, which matters for MFA. However it says nothing about what happens after login (whether a session is persisted, whether the call blocks, timeouts, or what the caller must do next).

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 states the action, the target, and the motivating condition with zero 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?

For a zero-param tool with no output schema the description is nearly sufficient, but given the sibling set_session_cookie it should explain the relationship (does this establish the session used by the other tools?) and the expected post-login flow. That connective 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?

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify; 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?

States a specific verb+resource: it opens a browser window so the user can manually log in to SLIIT Courseweb. That clearly distinguishes it from siblings like set_session_cookie or scrape_page, though it never names the sibling it complements.

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 parenthetical '(useful for MFA)' implies the situation that calls for this tool, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g., when a non-interactive cookie/session path is preferred).

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?

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: not whether an authenticated session is required, not whether the result is paginated or cached, not what happens if the user is not enrolled in any modules.

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 or redundant restatement of the tool name. Every word earns its place.

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

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

For a zero-parameter list tool with no output schema and no annotations, the description should at minimum cover the auth/session prerequisite and what the returned module list looks like. Neither is addressed, leaving the agent to infer setup steps from sibling tool names.

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 of 4 applies. The stated scope ('enrolled modules') is the only semantic content and it is consistent with the empty 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 ('modules') with scope ('enrolled') and platform ('SLIIT Courseweb'), so it is distinguishable from get_announcements and get_deadlines. It does not, however, differentiate itself from near-neighbours like check_module_updates or sync_module.

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

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

There is no when-to-use guidance and no alternatives named, even though sync_module and check_module_updates operate on the same resource. The presence of set_session_cookie and interactive_login siblings implies an auth prerequisite that is never mentioned.

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?

No annotations are provided, so the description carries the full behavioral burden. It says it returns text content (implying a read), but never states whether authentication is required (the presence of set_session_cookie and interactive_login siblings strongly suggests it is), whether the scrape is rate-limited, how dynamic content is handled, or what happens on failure.

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

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

A single short sentence with the verb and resource front-loaded and no redundancy. The 'investigate the layout' clause is the only slightly expendable element.

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 tool with no output schema, the description adequately conveys the return type (text content). However, with no annotations and a sibling set centered on sessions and logins, the omission of auth expectations leaves a real gap for an agent deciding whether it can call this directly.

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% with a single documented url parameter, so the baseline is 3. The description adds only the qualifier 'any Courseweb URL', which scopes the domain but adds no format or syntax 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?

States a specific verb (scrape) and resource (text content of a Courseweb URL), which distinguishes it from download_file and the login/session siblings. The trailing phrase 'to investigate the layout' muddies the intent slightly by framing it as a debugging aid rather than a content-retrieval tool.

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

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

'To investigate the layout' implies a use case but gives no guidance on when to prefer this over download_file or the structured siblings like get_announcements. No exclusions, prerequisites, or alternatives are named, leaving selection to inference.

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

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

No annotations, so the description carries the full burden. It does add real behavioral context by explaining this is a manual substitute for browser login, but it omits key traits: whether it overwrites an existing cookie, whether the value is validated, what happens on an invalid/expired cookie, and whether the session persists across calls.

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

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

One sentence with a purposeful parenthetical; nothing is padding and the core action is front-loaded before the use-case qualifier.

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 setter with full schema coverage and no output schema, the description covers purpose and scenario adequately. It could be stronger by explicitly relating itself to interactive_login as the alternative auth path and noting error/validation behavior, but the essentials are present.

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 explains the single 'value' parameter and where to obtain it (DevTools). The description adds no format, validation, or encoding detail beyond the schema, 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?

States a specific verb and resource ('set the MoodleSession cookie'), which is unambiguous and distinguishable from list/scrape siblings. The parenthetical about headless VMs further narrows the scenario, though it never names the browser-based alternative (interactive_login) directly.

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

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

Gives a clear when-to-use condition: headless VMs where a browser isn't available. It implies the alternative (browser-based interactive login) without explicitly naming it or stating exclusions, so it falls just short of full when/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?

No annotations exist, so the description carries the full behavioral burden, yet it omits the key question for a tool named 'sync': whether existing files are skipped, overwritten, or duplicated. It also says nothing about auth/session prerequisites (siblings include set_session_cookie/interactive_login), runtime cost of a bulk download, or rate limits.

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

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

One sentence, zero filler, with the operation and target front-loaded. It could have used a few more words to cover sync semantics without becoming bloated.

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

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

For a side-effecting download tool with no annotations and no output schema, the description should disclose overwrite behavior and what is returned (count, paths, errors). Those gaps leave an agent unable to predict the effect of repeated invocations.

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% – both courseId and outputDir (with default ./downloads) are fully documented, so baseline is 3. The description's 'PDFs, lab sheets, etc.' describes content types, not parameters, and adds no syntax or format meaning beyond the schema.

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

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

States a specific verb ('bulk download') and resource ('all files ... from a specific course module'), and the 'bulk' wording implicitly contrasts with the sibling download_file (single file). It never names that sibling explicitly, so 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?

No guidance on when to use this rather than download_file, scrape_page, or check_module_updates. An agent must guess whether sync means 'fetch only new/changed files' or 're-download everything'.

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