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 convey that the operation is a non-mutating read ('Show') and characterizes the returned content (sections, materials, links, activities), but says nothing about login/auth prerequisites, pagination, or failure modes for an unknown course identifier.

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

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

Two sentences, zero filler, with the primary action front-loaded and the parameter clarification trailing. 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?

For a single-parameter browse tool with no output schema and no annotations, the description covers purpose and argument format adequately. The notable remaining gap is that it never signals the likely prerequisite of being logged in (moodle_login is a sibling), which an agent would need to know before calling.

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 description compensates well by specifying that `course` accepts a course id, a short name, or part of the full name. That is meaningful added semantics an agent could not infer from the bare string parameter, though exact matching behavior (case sensitivity, ambiguity on partial matches) remains 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 ('Show') and resource (a course's sections with their materials, links and activities), so an agent can tell it apart from moodle_download at a glance. It does not explicitly contrast itself with moodle_courses, which also operates on course-level data.

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

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

Usage is implied by the purpose – browse the contents of a known course – but there is no explicit 'use this when' statement and no mention of alternatives such as moodle_courses (list all courses) or moodle_download (fetch a file). The only guidance offered concerns the `course` argument format, not when to pick this tool.

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 usefully discloses ordering ('most recently accessed first'), but omits auth requirements, pagination behavior, read-only assurance, and any rate-limit or safety context.

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 waste. The parenthetical ordering detail is useful and 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 an output schema, the description covers purpose and ordering. It lacks usage guidance and auth context, but the output schema handles return values, making it nearly 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter information, but there are no parameters to describe.

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 ('user's enrolled Moodle courses') with an ordering scope. It is clear enough to distinguish from siblings like moodle_browse or moodle_sync, but it does not explicitly name or differentiate against any alternative 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?

No when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The description implies usage only through its statement of function, but offers no context, prerequisites, or routing advice.

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. It usefully discloses the sort order ('soonest first'), but omits whether the call is read-only, any auth/precondition, and how the limit interacts with results. That is a meaningful gap for a zero-annotation 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 sentence with no waste, front-loading the resource and the ordering constraint. Nothing extraneous is present.

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?

The output schema means return values need no explanation, and the tool is simple (one optional param, no nesting). However, the undocumented 'limit' parameter and absence of any usage or behavioral context leave the definition just adequate rather than 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 the description must compensate, yet it never mentions the single 'limit' parameter or its default of 20. The meaning of the only parameter is left entirely undocumented.

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

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

The description gives a specific verb and resource ('List upcoming assignments, quizzes and other dated activities') and adds scope ('upcoming', 'soonest first'). It is easily distinguishable from siblings like moodle_login, moodle_courses, or moodle_sync, though it does not explicitly name or contrast with any of 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 by the phrasing — an agent can infer this is the tool for deadlines — but there is no explicit when-to-use, when-not-to-use, or comparison to alternatives such as moodle_browse or moodle_courses. Guidance is left 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?

With no annotations, the description must carry full behavioral burden. It discloses the save location and optional subdir, but doesn't state whether it overwrites existing files, how it handles large files, whether authentication is required, or what happens on failure. The 'saved under the download folder' detail is useful but incomplete for a file-writing 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?

Two compact sentences, front-loaded with the action, then the parameter workflow and save location. Nothing is wasted and the essential information comes first.

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 file-download tool with no annotations and no output schema, the description gives the minimum: what it does, the key input source, and the save behavior. It's incomplete regarding authentication, failure modes, overwrite behavior, and the filename parameter, but covers the basic call path.

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 document all three parameters. It explains fileurl (from moodle_browse) and subdir (optional folder), which is helpful, but it completely omits filename. One of three parameters is undocumented in both schema and description, a significant gap.

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 (Download) and resource (one Moodle file), and it carefully distinguishes itself from sibling moodle_browse by explaining it consumes a fileurl from a browse result. However, it doesn't fully differentiate itself from moodle_sync, which might also retrieve files, leaving a minor ambiguity about when to prefer a direct download over a sync.

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?

It gives clear context: pass the fileurl from a moodle_browse result, and optionally place it in subdir. It doesn't explicitly exclude other usage patterns or mention prerequisites like requiring authentication or an active session, but the workflow guidance is solid and actionable.

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 a visible side effect (a Chrome window opens on the user's Mac), required human action (SSO + MFA), the persistent artifact (a saved token), and the non-obvious silent-refresh path. It omits failure/timeout behavior and any statement about what the caller sees on abort, which keeps it from a 5.

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 compact sentences that front-load the core action and then layer in the mechanism, user action, and silent-refresh optimization. Every clause earns its place; there is no filler or restated name/title.

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 interactive auth tool with no annotations and no output schema, the description covers the essentials: what opens, who acts, and what persists for downstream tools. The remaining gaps are the undocumented timeout parameter and unstated failure modes, which are modest against how much flow context is already given.

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 never mentions a timeout or its default of 300 seconds, so neither source explains what the value controls. The description compensates with valuable narrative about the login flow but adds nothing about the one parameter's meaning or units.

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 ('Sign in to Moodle') and immediately explains the mechanism: a Chrome window at the university sign-in page, SSO + MFA, and a saved web-service token. This clearly distinguishes it from siblings like moodle_status, moodle_courses, and moodle_sync, which operate on data rather than establishing the session.

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 makes the prerequisite relationship explicit: a token 'is saved for the other tools,' so an agent can infer this must be called before authenticated siblings. It also clarifies that a silent refresh means the tool 'often finishes without any window,' which frames the expected flow. It stops short of saying what to do when other tools fail due to auth, so it's clear context but not explicit when/when-not routing.

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 conveys that this is a non-mutating session inspection and enumerates the returned fields, but it says nothing about failure behavior (e.g. what happens when no session exists) or whether it touches the network.

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 with zero padding, front-loaded on the verb and resource, followed by the concrete data points returned. Nothing needs trimming.

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 must convey the return values, and it lists the three key pieces of session state. It falls just short by not indicating how the tool behaves when no valid session exists, which an agent checking login status would want to know.

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 has nothing to document and the baseline is 4. The description correctly does not invent parameter semantics and instead spends its words on returned state.

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 ('the Moodle session') plus the three things it reports: site, signed-in user, and download folder. That is clear enough for an agent to distinguish it from moodle_login or moodle_courses, though it never explicitly contrasts itself with those siblings.

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: calling a status tool makes sense to verify session/login state, likely before or after moodle_login. There is no explicit when-to-use statement, no mention of prerequisites, and no named alternative, so the agent must infer the context itself.

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 mostly delivers: it discloses destination-path resolution (SlideMate library vs ~/MoodleFiles), background execution, the literal {"running": true} return for the bulk mode, and the same-size skip rule. It omits auth/precondition requirements and any indication of whether a skipped file is reported, so it falls short of fully transparent.

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?

Both modes are front-loaded in the first sentence and the async contract is stated compactly with the literal return value. The text is dense but nearly every clause carries operational information; only the destination-path parenthetical is a slight detour.

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 correctly assumes responsibility for return shapes and does so for the bulk mode ("running": true plus polling instruction). It also explains the destination layout and skip rule. It stops short of describing what the with-course synchronous result contains, which leaves a gap for a tool with zero structured return documentation.

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` by spelling out accepted forms (id, short name, or partial name), which the schema's bare string type does not convey. However, `skip_existing` is only implied via "Existing files of the same size are skipped" and the behavior when set to false is never stated.

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") and clearly splits the two operating modes by presence of `course`. It distinguishes itself from moodle_sync_status by pointing at it as the polling companion, but says nothing to separate it from the sibling moodle_download, which an agent could easily confuse it with.

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 concrete when-to-use guidance for both branches: pass a course to download one course synchronously, omit it to bulk-download PDFs from all current courses in the background, and call moodle_sync_status to get the eventual result. It names the alternative tool for the async path, but offers no exclusion guidance versus moodle_download or moodle_browse.

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 discloses the polling behavior (progress while running) and the final return contents (summary, files per course, errors), which is useful. However, it omits authentication requirements, rate limits, and whether the call blocks, which are important for a status tool with no annotation coverage.

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 purpose and then describes the return shape. It is dense but has no wasted words. Slightly run-on, but acceptable.

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 and no annotations, the description compensates reasonably by describing the progress object and final result contents including errors. It doesn't cover authentication or polling frequency, but for a zero-parameter status endpoint it is mostly 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?

The tool takes zero parameters, so the baseline is 4. No parameter details are needed, and the description correctly does not introduce any.

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 purpose: reporting progress and final result of a sync started by moodle_sync without a course. It names the sibling that creates the sync and distinguishes itself as the status endpoint. Lacks explicit differentiation from moodle_status, but clearly differentiates from moodle_sync.

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 condition for when to use it: after starting a sync via moodle_sync without a course. Doesn't explicitly state when not to use it or what to use if a course was specified, but the context is sufficient for an agent to infer usage.

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