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

With no annotations, the description carries the full behavioral burden. It usefully discloses result ordering (newest first) and the default scope when `course` is empty, but says nothing about authentication requirements, pagination, or result limits. An output schema exists, so return shape is covered elsewhere, keeping this at an adequate 3.

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

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

A single sentence, front-loaded with the resource and ordering, followed by the two scoping cases. No filler and no restatement of the tool name.

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

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

For a two-parameter read tool with an output schema, the description covers purpose, scope branching, ordering, and both parameters' semantics. The only omission is auth/pagination behavior, which is minor given the schema already defines return values.

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: `days` is defined as the lookback window and `course` is described as accepting an id, a code, or a partial name, with the empty-string case meaning all current courses. It omits the default value of `days` (14), which the schema supplies.

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

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

States a specific resource (announcements), a time window (last `days` days), an ordering (newest first), and the two possible scopes (one course vs. every current course). No sibling tool covers announcements, so there is no ambiguity to resolve, and an agent knows exactly what it will get 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?

The description implicitly tells the agent when to use each mode: pass a course value for a single course, leave `course` empty for a cross-course sweep. It gives clear context but names no exclusions or alternative tools (e.g., nothing about when to prefer canvas_deadlines or canvas_courses instead).

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 disclosure burden. It adds real behavioral context by noting that file items carry a file_id intended for canvas_download (interop beyond the schema), but it omits whether authentication is required, whether the call is read-only, and any 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 tight sentences with no filler; the return contents are front-loaded and the cross-tool hint is appended last. Every clause earns its place.

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

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

With no output schema, the description responsibly enumerates the returned structure (modules containing files, pages, links, assignments with due dates). The only real gap for correct invocation is the unstated authentication prerequisite implied by the sibling canvas_login.

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 fully: the single `course` parameter is documented as accepting a course id, a course code, or part of the name. That resolves all ambiguity about valid input forms for the only parameter.

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 ('a course's modules') and enumerates exactly what each module contains (files, pages, links, assignments with due dates). This distinguishes it from sibling list tools like canvas_courses or canvas_deadlines without needing to name them.

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

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

Usage is implied — browse within a single course — and it points forward to canvas_download for file_id items, which is a useful handoff. However, it never states when to prefer this over canvas_courses or canvas_deadlines, nor any prerequisites such as needing canvas_login first.

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. It does disclose the key behavioral trait – default filtering to current courses – which is real value beyond the schema. It omits auth prerequisites (canvas_login), pagination/rate-limit behavior, and does not explicitly state that the operation is read-only.

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, front-loaded with the resource and the default behavior. Every clause earns its place with no filler.

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

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

For a simple read-only list tool with an output schema, the description plus schema is nearly sufficient – return values need not be described. The remaining gap is the missing authentication prerequisite and any note on result scoping, which would help an agent in a session that has not yet logged in.

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 include_past parameter, so the description must compensate. It does: 'current ones, unless include_past' explains exactly what the flag toggles, which the bare boolean title does not.

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?

Specific verb and resource: 'List the user's Canvas courses.' An agent immediately knows what it returns. It does not differentiate itself from siblings such as canvas_browse or canvas_deadlines, so it stops short of a 5.

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

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

The parenthetical clarifies the default scope (current courses unless include_past), which is implied usage guidance for choosing the flag. However, it names no alternative tool and states no when-not-to-use condition, so it is adequate but thin.

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 usefully discloses sort order (soonest first), the default window, and that submission status is included, but says nothing about auth requirements (a canvas_login sibling exists), pagination, or truncation limits for large course loads.

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 well-formed sentence with the resource list, window, and sort order front-loaded. No filler and nothing redundant.

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

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

For a simple one-optional-parameter read tool with an output schema, the description covers purpose, scope, ordering, and default adequately. Only auth/prerequisite context is absent, which is a minor gap given siblings like canvas_login exist.

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

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

Schema coverage is 0% and the single parameter is only typed as an integer with a default. The description supplies the actual semantics — the window in days — which the schema does not, though it merely restates the default value already present 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 precise resource set (assignments, quizzes, discussions) plus scope (due in the next `days` days) and ordering (soonest first). An agent can immediately tell this apart from canvas_announcements or canvas_courses without opening a 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 implied by the phrase 'due in the next `days` days (default 14)', which signals the upcoming-workflow context. However, there is no explicit when-to-use guidance, no when-not-to-use, and no sibling alternative named (e.g. vs canvas_courses for a full listing).

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. It does disclose a real behavioral trait: the write destination (<download folder>/<course>/, overridable via subdir). But it says nothing about authentication (canvas_login is a sibling), overwrite/collision behavior, or failure modes for an invalid file_id.

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

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

A single sentence that front-loads the verb and resource, then qualifies scope and destination. Every clause earns its place, with no restatement of the tool name or filler.

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

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

With no annotations, no output schema, and three undocumented parameters, the description leaves important gaps: whether a local path is returned, whether an existing file is overwritten, and whether login is a prerequisite. For a tool whose whole purpose is producing a local artifact, the post-download state is unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: file_id's source (canvas_browse) and subdir's role as a path override are explained, and course appears as a path segment. However, it never clarifies whether 'course' is an ID or a name, leaving the highest-ambiguity parameter unresolved.

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 ('Download one Canvas file') and scopes it to a single file rather than a batch, which cleanly separates it from the list-oriented canvas_browse and the bulk canvas_sync. It also identifies the provenance of the required file_id, so an agent can place it in the workflow without opening the schema.

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

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

The parenthetical that file_id comes 'from canvas_browse' implies the browse-then-download workflow, which is genuinely useful routing guidance. However, it never states when not to use this tool, nor does it distinguish itself from canvas_sync (bulk download) beyond the word 'one'. Usage is implied rather than explicit.

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 well: it discloses that a Chrome window may open, that the user must complete SSO and MFA, that the session is saved, and that a silent refresh often avoids the window. It does not mention failure modes, timeout behavior, or exactly when the window will appear, leaving minor gaps for a login tool.

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 two tight sentences with zero waste. The core purpose is front-loaded, followed by necessary operational detail. Every phrase earns its place without unnecessary repetition.

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

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

Given no annotations and no output schema, the description adequately covers the interactive login flow and session persistence. The only missing piece is any mention of the timeout parameter, which is the sole input and affects behavior. For a simple login tool, this is largely complete but not fully comprehensive.

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 parameter 'timeout_seconds' has 0% schema description coverage, and the description does not mention it at all. The agent receives no guidance on what the timeout controls or how to set it, so the description fails to compensate for the missing schema documentation.

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 begins with a specific verb and resource: 'Sign in to Canvas.' It explains the mechanism and outcome, and makes clear this is an authentication prerequisite for other tools ('session is saved for the other tools'). No sibling tool covers login, so this 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?

The description provides clear context: it is the sign-in tool and its session benefits other tools. It also notes that it 'tries a silent refresh first,' implying it can be called even when a session may exist. However, it does not explicitly state when not to use it or name alternatives, which keeps it from 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 must carry behavioral disclosure. 'Check' implies a non-mutating read, which is useful, and it discloses the information returned. However it says nothing about permissions, failure states (e.g., not signed in), or whether it has 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?

A single front-loaded sentence with no filler; the read target and the three returned facets are stated 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?

For a zero-parameter status tool with no output schema, the description usefully enumerates the returned values, largely covering the missing output documentation. Only the authentication/failure context is absent.

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 clarify; baseline applies. No misleading parameter claims are made.

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 ('Check') and resource ('Canvas session') and enumerates the exact facets returned: site, signed-in identity, and download folder. This distinguishes it in practice from canvas_sync_status, though it never names that sibling explicitly.

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

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

There is no statement of when to use this versus the many sibling tools (canvas_sync_status, canvas_login, canvas_courses). Usage is only weakly implied by the word 'Check', with no prerequisites or 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 behavioral burden and mostly does so: it discloses the on-disk target path, the SlideMate-vs-~/CanvasFiles fallback, the background-mode return value {"running": true}, and that existing files are skipped. It omits any authentication prerequisite (a canvas_login sibling exists) and gives no sense of volume or duration for the bulk mode.

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 destination path, then the two modes, then the polling instruction. Three sentences, each earning its place, with no restatement of the tool name or 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?

There is no output schema, but the description supplies the return contract for the async case ({"running": true}) and states the sync case 'returns the result'. For a two-parameter, no-annotation tool this is nearly complete; only the auth prerequisite and the shape of the eventual result are left unstated.

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

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

Schema coverage is 0%, so the description must compensate and largely does: `course` is described as accepting an id, code, or partial name and as optional (the empty string drives the bulk mode), and the skip-existing behavior is surfaced. It never explains what skip_existing=false does or when a caller would want to override the default.

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 ('Download course files') plus the exact destination layout and the two operating modes (single course vs. all current courses). It does not explicitly differentiate itself from the sibling canvas_download, which a reader must infer from the phrase 'downloads every file in it'.

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 conditional: pass a `course` for a synchronous full download, omit it to fan out across all current courses in the background. It also names the follow-up tool (canvas_sync_status) and tells the agent to poll until a result appears, leaving nothing to inference about the async path.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses the running-state return shape and the final result contents, including summaries, per-course files, and errors. It omits polling interval or explicit read-only confirmation, but the status nature is evident.

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 compact sentence front-loads the tool's purpose and then describes the two output phases. The inline JSON example efficiently conveys the running-state shape without unnecessary prose.

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 status tool with no output schema and no annotations, the description explains both in-progress and completed returns adequately. It could add a note about polling until completion, but nothing essential for invoking it 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 has zero parameters, so there is no parameter semantics to document. Baseline 4 applies; the description does not need to add parameter details.

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—progress/result of a sync—and ties it to the sibling canvas_sync without a course. It clearly distinguishes this status tool from the sync starter and from general status tools, though it does not explicitly contrast with canvas_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 'started by canvas_sync without a course' gives clear context for when to use it: after starting a global sync. It does not spell out exclusions or name alternatives, but the intended usage is unambiguous.

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