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

No annotations are provided, so the description carries the full burden. Beyond the course-omission scoping behavior, it says nothing about read-only nature, auth requirements, or result 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?

A single efficient sentence with the scoping rule front-loaded. No waste, but it is arguably too terse for the schema gaps it must cover.

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 two-parameter read tool with no output schema, the description covers the course scope but leaves the days parameter and return shape unaddressed, leaving a real gap an agent must guess at.

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. It explains the course parameter's null/omitted behavior but says nothing about the days parameter (default 14) or what 'recent' actually bounds.

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) with clear scope: one course, or all current courses if course is omitted. The listing verb is implied rather than explicit, but an agent can distinguish it from siblings like bb_courses or bb_upcoming.

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 'for all current courses if none is given' implicitly tells the agent that omitting course widens scope, which is useful. However, it names no alternatives (e.g., bb_upcoming) and gives no condition for choosing between them.

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. 'List' implies a read-only operation and it usefully discloses the returned fields (titles, types, text, links, grade columns), but it says nothing about pagination, result size, or authentication prerequisites.

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, front-loaded with the action and return content, with the parameter clarification appended. Nothing 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 low-complexity read tool with no output schema and only two parameters, the description covers purpose, returned fields, and the flexible `course` input. Gaps remain around folder_id semantics and pagination, but the core call path is clear.

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. It does well for `course`, explaining it accepts a code, partial name, or id, but `folder_id` is only hinted at by the parenthetical — its format, validity constraints, and whether it must belong to the given course are unspecified.

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 (content in a course or one folder) and enumerates the fields returned. It is implicitly distinct from bb_courses, but it never names a sibling or explicitly contrasts itself with the course-listing 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?

The '(or inside one folder)' clause implies when to pass folder_id, but there is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives such as bb_courses or bb_download. Usage must be inferred.

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 burden. It clarifies that include_all=True broadens results to every course and organisation, but omits any auth prerequisite (bb_login) and read-only/side-effect guarantees, leaving behavioral profile partly implied by the verb '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 front-loaded sentence with the core purpose first and the parameter nuance in a compact parenthetical. No filler or redundancy.

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 optional boolean parameter, an output schema present, and no nested objects, the description is nearly complete for a simple list tool. The main omission is any mention of the login/authentication prerequisite that sibling tools imply.

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 schema only labels the field 'Include All' as a boolean defaulting to false. The description compensates by explaining that the flag switches from 'current' courses to every course and organisation you're enrolled in, which is genuine 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 (List) and resource (Blackboard courses) with a scope qualifier (current). It is clear what the tool returns, but it never names or contrasts itself with siblings like bb_browse or bb_upcoming, 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?

There is no explicit guidance on when to use this versus alternatives such as bb_browse, bb_upcoming, or bb_download. The parenthetical hints at the include_all toggle but says nothing about selection context or prerequisites.

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 discloses only that paths are returned; it says nothing about authentication requirements (bb_login), whether files are written to disk or overwritten, rate limits, or what 'local' means relative to the server/client.

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 zero filler, and the purpose is front-loaded ahead of the return-value note. It is efficient, though it could have used the spare space to document parameters rather than stopping so early.

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 two-parameter tool with no output schema, the description does state the return value ('local paths'), which covers the output side. However, with no annotations and 0% schema coverage, the missing parameter meanings and side-effect details leave the definition only minimally complete.

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

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

Schema description coverage is 0%, so both parameters are undocumented in structured data and the description must compensate. It only vaguely implies a content item via 'one content item' and never explains what 'course' means or the expected identifier format for 'content_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 a specific verb (Download) and resource (every file attached to or embedded in one content item), which is more precise than the bare name bb_download suggests. It does not differentiate itself from siblings like bb_sync, which could plausibly also fetch content, 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?

There is no explicit guidance on when to use this tool versus bb_sync or bb_browse, and no prerequisites or exclusions are stated. 'One content item' weakly implies the granularity, but the agent must infer everything else.

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 at all, the description carries the full burden and does a good job: it discloses that a Chrome window opens, that a human must complete SSO + MFA, and that a silent refresh is attempted first so it often completes headlessly. It still omits failure/timeout behavior and what state is persisted on success.

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 action, then the interaction model, then the silent-refresh nuance. Every clause earns its place and there is 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 an auth tool with no output schema and a thin input schema, the description supplies the essential mental model an agent needs (human-in-the-loop, browser window, silent refresh). The remaining gap is the undocumented timeout parameter and the absence of any statement about what a successful or timed-out result looks like.

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 parameter (timeout_seconds) with 0% schema description coverage, and the description never mentions it or explains what it bounds (presumably how long to wait for the student to finish SSO/MFA). The description therefore adds no meaning beyond the bare default 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 ('Sign in to Blackboard'), which is unambiguous and clearly distinct in kind from the data-retrieval siblings (bb_courses, bb_browse, bb_download). It does not explicitly name a sibling or say where it sits in the workflow relative to them, so it falls 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 is implied rather than stated: an agent can infer this is the prerequisite auth step, and the note that it tries a silent refresh first hints it is safe to call even when a session may already exist. There is no explicit when-to-use, when-not-to-use, or ordering guidance versus bb_status or the other bb_* tools.

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 and no output schema, the description carries the full behavioral burden. It lists content categories but never confirms this is a non-mutating read (vs. something that triggers a sync/authenticates), says nothing about auth state needed, rate limits, or how stale the status might be — notable given the adjacent bb_sync and bb_sync_status tools that do act.

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 compact sentence with no filler, listing the three payload areas up front. It reads as a fragment rather than a complete sentence, but nothing 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 zero-parameter status tool with no output schema, the description does sketch the returned categories, which is useful. However, it omits the read-only guarantee and any differentiation from bb_sync_status, leaving ambiguity that a status tool's description should resolve.

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 the schema-based baseline of 4 applies. No parameter meaning is required from the description, and none is offered or needed.

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 enumerates what the tool reports (Blackboard instance, account, download path, last sync time), which hints at a read-only status/info query, but it never states a verb or that it 'returns' anything — it is a bare noun phrase. It also fails to distinguish itself from the sibling bb_sync_status, which sounds nearly identical in scope.

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 context, no prerequisites, and no routing between this tool and bb_sync_status or bb_login. The agent must guess from the field list alone whether to call this or the closely-named sibling.

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 and does well: it discloses incremental behavior ('only new or changed files are fetched'), the on-disk output structure, and the asynchronous background execution model with a follow-up tool. It omits auth requirements, what happens on partial failure, and whether existing files are overwritten.

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

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

Three short sentences, front-loaded with the action and destination, then behavioral note, then the async escape hatch. No filler; every clause adds information.

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?

No output schema and no annotations, yet the description covers what is downloaded, where it lands, the incremental rule, and the async pattern with a named continuation tool. Missing only auth/error-case detail, which is minor for a two-parameter 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?

Schema coverage is 0%, so the description must compensate, and it largely does: `courses` is framed as the optional subset selector versus the default of all current courses, and `wait_seconds` is tied to the background-completion check. It still never says what form a course identifier takes (name, ID, code).

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 (the PDFs: slides, readings, worksheets) plus the scope (every current course, or just the `courses` subset). The destination layout <download folder>/<course>/<week>/ further disambiguates it from the single-target bb_download sibling.

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 clear context: it is the bulk/whole-course fetch, and it explicitly routes the agent to bb_sync_status when the background job exceeds wait_seconds. It does not, however, contrast itself with bb_download or state prerequisites such as needing to be logged in via bb_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 usefully discloses the two behavioral states (in-progress progress vs. terminal result), which is real signal. It omits other relevant behavior: whether the call blocks, whether it errors if no sync has ever run, and whether the result persists across sessions.

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 compact sentence with the two modes stated up front and no filler. The parenthetical is slightly awkward but costs the reader almost nothing.

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 is the only source of information about the return value, yet it only gestures at 'progress' or 'the result' without characterizing either shape or the fields an agent should expect. For a status-polling tool this is adequate but leaves a meaningful gap.

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 the baseline is 4. Nothing in the description distorts or contradicts 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?

The description states a specific resource (bb_sync) and what the tool returns: progress while a sync runs, or the result of the last sync. That is clear enough for an agent to know this is a status/result reader. It does not, however, differentiate itself from the sibling bb_status, which could plausibly also be read as a status 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 explicit when-to-use guidance, no prerequisite stating a sync must first be started with bb_sync, and no mention of the alternative (bb_status) or when to prefer it. The temporal framing ('while running' / 'most recent') implies usage but leaves the agent to infer the trigger 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that the call is read-only, whether a prior bb_login session is required, whether overdue/past items are excluded, or how results are ordered or returned, leaving meaningful gaps for an unannotated 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?

A single compact sentence with the scope ('next `days` days') front-loaded and no filler. Every clause (content types, time window) 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 listing tool with one optional parameter, no output schema, and no annotations, the description should at minimum cover the login prerequisite (bb_login is a sibling) and what the returned items look like. Neither is addressed.

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 `days` parameter has no schema description, but the prose does define it as a forward-looking window ('for the next `days` days'), which adds real meaning. It still omits the default of 21 and the accepted range or edge cases, so it only partially compensates.

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 (Blackboard due dates) and enumerates the content types it returns (assignments, quizzes, Turnitin), so an agent can distinguish it from bb_announcements or bb_courses. It never explicitly contrasts itself with those siblings, but the intent is unambiguous from the text 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?

The description implies a forward-looking time window ('next `days` days') but gives no when-to-use guidance, no prerequisites, and never names an alternative tool for other date ranges or overdue items. Usage must be inferred entirely from the name.

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