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

No annotations are supplied, so the description carries the full burden for a mutation tool that writes into a user's Reminders database. It says nothing about whether repeated calls create duplicates, whether it is idempotent, what each reminder looks like, or that Reminders access must be authorized — all material facts for an agent deciding to invoke it.

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

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

The purpose sentence is front-loaded and short, and the Args block is compact with no filler. The docstring formatting is slightly mechanical but does not waste 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 values need not be described. But for an unannotated write operation with zero schema descriptions, the definition omits side effects, duplicate behavior, and authorization requirements — the gaps an agent most needs closed 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 0%, so the description must compensate, and it largely does: it explains that days_ahead is the look-ahead window for assignments and that account defaults to the active one. The only shortfall is that account does not point to list_school_accounts for valid values.

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

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

The description states a specific verb and resource: 'Add upcoming deadlines to macOS Reminders.' That is far more informative than the bare name and identifies the target application. However, it does not distinguish itself from the sibling get_deadlines, which presumably surfaces the same deadlines without writing them.

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

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

'Upcoming deadlines' plus the days_ahead window implies when the tool applies, but there is no explicit when-to-use statement, no mention of the sibling get_deadlines as the read-only alternative, and no prerequisites (macOS Reminders availability, permissions, account already switched).

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 burden and does real work: it discloses that download_path does not mutate the saved setting ("never changes it"), that account defaults to the active account, and that folder layout depends on flat. It does not cover overwrite behavior for existing files, directory creation, or failure modes for a write-to-disk operation.

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

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

The one-line purpose is front-loaded and the Args block is terse with no filler. The raw docstring format is slightly less scannable than prose, but no sentence is wasted.

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

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

For a six-parameter filesystem-writing tool, the definition covers selection, location, layout, and account routing, and an output schema exists so return values need no explanation. The remaining gap is file-collision and path-permission behavior, which an agent would want before calling it on a populated directory.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every one of the six parameters gets meaning, including accepted date syntax for since (YYYY-MM-DD or "7d"), the default-inheritance semantics of download_path and account, and the layout consequence of flat. This is substantially more than the bare types in the schema.

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

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

The opening line names a specific verb and resource ("Download files from a Canvas course") and immediately bounds scope with "all of them, or a selection." It also routes to the sibling list_course_files for obtaining file ids, so an agent can tell it apart from the listing tool without opening either schema.

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

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

Usage context is clear: bulk download by default, narrowed via file_ids or since, and file_ids are explicitly sourced from list_course_files. There is no explicit when-not guidance (e.g., use get_course_page for single pages, or list_course_files to preview before downloading), which keeps it 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?

With no annotations, the description carries the disclosure burden and does reasonably well: it identifies the operation as a read, describes listing order (module pages first), discloses the student-visibility caveat that explains empty results, and describes the return payload (page text plus file links tagged with `section` and `hidden`). It omits auth/account-switching mechanics and any failure modes beyond the hidden-list caveat.

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 action and mode switch, then a compact Args block and a one-line Returns block. Every sentence carries information; only minor waste is the slightly redundant restatement of return values already covered by the output schema.

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

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

For a 3-parameter tool with no annotations, the description covers all parameters, both operating modes, list ordering, and visibility caveats. Since an output schema exists, the return description is optional garnish rather than a gap; only account/error handling is left implicit.

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%, yet the Args block fully compensates: `course` accepts an id, code like "7.36", or name fragment; `page` accepts a title fragment like "L15" or a url slug; `account` defaults to the active account. These are exactly the disambiguations an agent needs and none exist in the schema.

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

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

States a specific verb and resource ("Read a Canvas Page, such as a lecture page with its readings") and explicitly defines a second mode ("Without `page`, list the course's pages"). The distinction from file-oriented siblings like list_course_files and get_deadlines is evident from the object being read.

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 an explicit condition that switches behavior: omit `page` to list, supply `page` to read. It also warns that many courses hide the Pages list from students, which tells the agent to expect empty listings. It stops short of naming sibling tools as alternatives or saying when to prefer list_course_files.

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

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

With no annotations, the description carries the full behavioral burden and does not state that this is a read-only, non-destructive call, nor what credentials/account linkage are required for Canvas and Gradescope. It discloses the two sources and the default lookahead window, but says nothing about what happens when an account isn't linked to one of the platforms or whether results are merged/deduplicated.

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

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

The one-line purpose is front-loaded and the Args block is compact with no redundant wording. The Python-style Args formatting is slightly out of place for a JSON tool definition but costs nothing in clarity.

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

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

An output schema exists, so return values needn't be explained, and only two optional parameters are involved. Still missing for a cross-platform aggregation tool: what happens with unlinked accounts, whether both sources are always queried, and any time-zone assumption on the deadline window.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially: days_ahead is defined as the lookahead window with the same default of 14, and account is described as the school account with a default to the active one. It still doesn't say what form account takes (name, ID, or a value from list_school_accounts), leaving ambiguity for a 0%-coverage 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 and resource ("Get upcoming deadlines") plus the two data sources (Canvas and Gradescope), which distinguishes it from siblings like list_courses or add_to_reminders. It does not explicitly say how it relates to list_courses (which presumably lists assignments), so the differentiation is implicit rather than stated.

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

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

No guidance on when to call this versus list_courses, list_course_files, or add_to_reminders. The only contextual hint is that account defaults to the active account, implicitly pointing at switch_school_account, but no explicit when/when-not conditions are given.

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

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

No annotations are supplied, but the tool is a zero-argument read, so the behavioral surface is small and 'get the current default' implies a non-mutating read. The description does not say what is returned when no custom path is configured (e.g. an OS default), which is the one behavioral detail an agent might need.

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 resource and scope are stated immediately with nothing extraneous.

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 zero parameters and an output schema covering the return value, the description is nearly complete. The only missing element is the fallback behavior when no download path has been set, a minor gap given the tool's simplicity.

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 and the baseline of 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 pair (get + current default download path) scoped to Canvas files, which cleanly contrasts with the sibling set_download_path. It stops short of naming that sibling explicitly, so an agent must infer the pairing from the get/set naming.

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 get/set naming against the sibling set_download_path makes the intent reasonably obvious, but there is no statement of when to call this versus set_download_path or any prerequisite conditions.

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 burden and does well: it enumerates every source scanned (modules, assignments with attachments and description links, Files tab, Pages, announcements) and discloses dedupe-by-file-id, which tells the agent the result set is normalized rather than raw. It implies a read-only no-side-effect operation via 'without downloading', but never explicitly states that nothing is written to disk or that auth/account context is required.

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

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

The summary sentence is front-loaded and does the heavy lifting before any parameter detail, and the Args block is scannable. Slight verbosity in the nested compare_dir explanation, but every clause conveys usable information rather than filler.

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

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

An output schema exists so return values needn't be explained, yet the description still discloses the local.status vocabulary the agent will encounter. For a four-parameter read tool with no annotations, the description covers sources, dedupe, filtering formats, and the compare mode — 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 0%, so the description must compensate and it does: course accepts an id, code like '20.201', or name fragment; since accepts YYYY-MM-DD or relative '7d'; compare_dir explains the matching strategy (name+size then content hash, any layout) and the have/changed/missing statuses it produces; account defaults to the active account. All four parameters gain meaning not present in the bare 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 and resource ('List every file... for a course') and immediately scopes it against the sibling tool: it lists exactly what download_course_files would fetch, 'without downloading'. An agent can distinguish this preview tool from its download counterpart without opening either schema.

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

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

Usage is strongly implied by the contrast with download_course_files — this is the inspect-before-you-download path — and the compare_dir parameter hints at a sync-check workflow. However, it never states an explicit 'use this when...' rule or any when-not guidance, leaving the agent to infer the workflow position.

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 does little: it does not say whether this returns only enrolled courses or every course visible to the account, whether archived/concluded courses are included, whether results are paginated, or whether any permission is required. Because an output schema exists, return shape need not be described, but the scope and safety profile of the call remain undisclosed.

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

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

The definition is short and the core purpose is front-loaded in the first sentence. The Python docstring 'Args:' formatting is slightly noisy but does not obscure meaning, and no sentence is wasted.

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

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

For a simple one-parameter list tool with an output schema, this is close to adequate, but the absence of annotations plus the undefined course scope (enrolled vs. all, active vs. concluded) leaves a real gap an agent would want filled. The default-account behavior is a useful addition that partly offsets this.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'account' parameter. It does partly: it explains the parameter is the school account and that it defaults to the active account, but it never says what form the value takes (name, ID, slug) or how to discover valid values via list_school_accounts.

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 and resource ('List available courses from Canvas'), which is clear enough to distinguish it from siblings like list_course_files or get_course_page. It does not, however, explicitly differentiate itself from account-management siblings such as list_school_accounts or state whose courses (enrolled vs. all in the account) are returned.

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

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

There is no when-to-use guidance, no exclusions, and no mention of when to call switch_school_account or list_school_accounts first. The only usage signal is the parenthetical that account defaults to the active account, which is helpful context but not selection 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 are supplied, so the description carries the full behavioral burden. It discloses scope (configured accounts) and that an active flag is included, but says nothing about permissions, whether the list is environment- or user-scoped, or whether any state changes—though the read-only nature is strongly implied by 'List'.

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 verb and resource, with the active-account detail immediately after. Nothing is padded or repeated from the schema.

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 structure needs no explanation, and with zero parameters the surface area is small. The only shortfall is the absence of guidance tying it to switch_school_account, which would fully close the loop.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline credit applies. The examples of account identifiers (columbia, mit) give useful context about what the returned values look like.

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 pairs a specific verb (List) with a specific resource (configured school accounts) and adds that the active one is marked, which separates it from the mutation sibling switch_school_account. It does not name the sibling explicitly, so routing relies on the reader inferring list vs switch.

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 discovery step before switching accounts, but the description states no when-to-use condition, no exclusions, and does not point at switch_school_account as the follow-up action.

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 disclosure burden, yet it says nothing about persistence (is this saved across sessions?), whether the directory must already exist, whether missing directories are created, or whether existing files are affected. For a configuration-mutating tool this leaves the agent without the information needed to predict side effects.

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

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

The body is a single front-loaded sentence followed by a brief Args block, with no filler. It is short almost to a fault, but nothing is wasted or 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?

An output schema exists, so return values need not be explained, but the tool mutates a persistent setting with zero annotation coverage and an undocumented parameter. For a mutable-configuration tool the description should at minimum cover persistence and directory expectations, and it covers neither.

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

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

Schema description coverage is 0%, so the description must compensate, but "Path to save downloaded files to" only restates the parameter name. It omits absolute vs. relative paths, platform-specific formats, whether a trailing separator or file name is expected, and permission requirements.

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 (set) and resource (default download path for Canvas files), which is clear enough to act on. It does not differentiate from the sibling get_download_path_info, which reads the same setting, so the read/write split must be inferred from the names alone.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., whether download_course_files depends on this setting), and no reference to the sibling tools. The agent must guess the relationship between setting the path and actually downloading files.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that the setting persists across restarts, which signals global state mutation, but says nothing about validation of the account name, what happens on an unknown account, or whether the switch affects the output of siblings like get_deadlines and list_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?

The description is short and front-loaded with the action and the persistence note, with no wasted prose. The docstring-style "Args:" block is slightly mechanical but earns its place by supplying the only parameter examples available.

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 explained, but for a stateful switch affecting many sibling tools the description should say where valid account names come from and what an invalid name does. As written it is minimally sufficient but leaves the main failure mode undocumented.

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

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

Schema coverage is 0%, so the description must supply meaning, and it does add two concrete examples ("columbia", "mit") and a format hint (account name). However, it does not indicate whether these are the only valid values or that list_school_accounts enumerates them, leaving the parameter only partially specified.

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?

Description states a specific verb and resource ("Switch the active school account"), which is unambiguous and clearly distinct from the sibling list_school_accounts. It stops short of explicitly naming that sibling as the way to discover valid accounts, so it does not fully differentiate.

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

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

There is no guidance on when to call this versus list_school_accounts, nor any prerequisite such as checking which accounts exist before switching. The only contextual hint is that the change persists, which is behavioral rather than usage guidance.

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