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

With no annotations, the description carries the full burden, and it does disclose one genuinely non-obvious behavior: file URLs are token-redacted and must be exchanged via download_file. It omits pagination, permission/auth requirements, and what happens for an invalid or inaccessible courseid.

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 resource scope front-loaded and the important redaction caveat immediately after. Every sentence 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?

An output schema exists, so return-value detail is not required. For a one-parameter read tool the description covers the essential pitfall (redacted URLs needing download_file); only the usage routing and permission context are thin.

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 courseid parameter has 0% schema description coverage, so the schema adds nothing. The description does not clarify the parameter at all, though courseid is largely self-evident given the sibling list_courses tool.

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?

Names the specific resource contents returned (sections, activities, files) scoped to a course, which distinguishes it from list_courses and list_assignments. It lacks an explicit verb ("Retrieve/Get"), reading as a noun-phrase fragment, but the resource 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?

Gives one concrete routing rule: pass redacted file URLs to download_file. It does not say when to choose this over list_assignments or list_courses, nor does it state prerequisites such as needing a valid courseid or enrollment permission.

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 disclosure burden. It does reveal useful behavior: the file is written to dest_dir (default ~/Downloads/ispace), the return value is the saved path, and inputs are restricted to iSpace URLs. It is silent on overwrite behavior, directory creation, authentication needs, and file size limits, all of which matter for a filesystem write.

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, zero filler, with the core action and the value source front-loaded before the destination and return details.

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 two parameters, no output schema, and no annotations, the description covers the essentials: provenance of the required input, destination default, return value, and URL restriction. Overwrite and auth behavior remain unaddressed but are secondary for a simple downloader.

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: fileurl is defined by its provenance and allowed domain, and dest_dir is given an explicit default path. It stops short of describing path syntax or whether dest_dir is created if absent.

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 (an iSpace file), and names the sibling tools (course_contents / list_assignments) that produce the fileurl. An agent can distinguish this tool from the listing siblings 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?

It indicates where the fileurl value comes from (course_contents / list_assignments) and adds an exclusion: 'Only iSpace URLs are allowed.' That exclusion tells the agent when not to use the tool. It does not name an alternative downloader for non-iSpace URLs, which is the only missing piece.

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 must carry the behavioral load. It usefully discloses the timezone semantics of due dates (default Asia/Shanghai) and the default scope, but says nothing about pagination, volume, or permissions; the read-only nature is only 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?

Two compact clauses, front-loading the tool's action and folding the timezone and scope rules into a parenthetical. Nothing is redundant, though the parenthetical mixes two unrelated facts (timezone and default scope).

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 parameter and an output schema present, the description is nearly sufficient: scope, default behavior, and timezone are all covered. Only sibling differentiation and filtering granularity are 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?

Schema coverage is 0%, so the description does the work for the single parameter by explaining that omitting courseids widens scope to all enrolled courses. It does not clarify that courseids is an array of integers or whether invalid/unenrolled ids are tolerated.

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 assignments") and adds that results carry due dates. It does not differentiate from the closest sibling, upcoming_deadlines, so an agent must infer the boundary itself.

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 the key usage rule for the optional filter: omit courseids to cover all enrolled courses. It offers no guidance on when to pick this over upcoming_deadlines or submission_status, which is the main selection risk among siblings.

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

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

With no annotations, the description carries the full behavioral burden, and 'the user's enrolled' usefully discloses that results are implicitly scoped to the authenticated user rather than all courses. However, it does not state whether archived/completed courses are included or how many results are returned, and read-only status is only 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 no filler; the parenthetical field list is compact and informative rather than 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?

An output schema exists, so the description need not explain return values, and with no parameters there is little else to specify. The only gap is scope ambiguity about which enrollments count (active vs. completed), which slightly matters for a 'user's courses' list.

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. The description correctly adds nothing parameter-related and instead clarifies the return contents, which is the only useful semantic detail available.

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 the user's enrolled iSpace courses') and even enumerates the returned fields (id, name, progress). An agent can distinguish it from siblings like list_assignments or course_contents, though the description never explicitly contrasts with 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 only implied: the agent infers it should call this when it needs the user's course roster. There is no explicit when-to-use versus when-not, and no mention of the sibling tools (course_contents, list_assignments) that operate on a single course.

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 behavioral burden alone. It discloses the returned fields (name, userid, available functions), which is helpful, but says nothing about permissions required, whether it is a safe read, or what happens with token scopes. Those omissions matter for a tool with zero structured behavioral metadata.

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 that front-loads the primary purpose and then parenthesizes the returned fields. Every clause carries information 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?

With no output schema, the description must convey return values, and it does so only for the user portion while leaving 'site info' entirely unspecified. It is adequate to identify the tool, but an agent cannot predict the full response shape or error behavior from this text.

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 to disambiguate; the baseline of 4 applies. The description correctly does not invent parameter guidance for a zero-argument call.

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

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

The description names the resource precisely — Moodle site info plus the logged-in user — and enumerates the identity fields returned (name, userid, available web-service functions). It does not contrast with siblings like list_courses or course_contents, but the subject matter is distinct enough that confusion is unlikely.

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 statement or list of alternatives. Usage is only implied: the mention of the logged-in user and available web-service functions suggests it is the natural first call to identify the caller or discover which Moodle functions are enabled. An agent can infer that but must do the work 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?

No annotations are provided, so the description carries the entire behavioral burden and does little with it: it never states that this is a read-only lookup, what permission or enrollment context is required, or whether it exposes other students' data. Neither the return shape nor the set of possible status values is described, and there is no output schema to fall back on.

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 that front-loads the resource and scopes it immediately, with the argument hint placed in parentheses so it does not interrupt the core statement. There is no filler, though the phrasing is telegraphic to the point of omitting a verb.

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 read tool with no annotations and no output schema, the definition covers what the tool is and where the argument comes from, which is the minimum viable set. It leaves the agent guessing about return contents (per-student breakdown? grade, submission timestamp, late flag?) and does not clarify whether calling it without a submission returns an error or an empty status.

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 assignid parameter, so the description must supply the meaning — and it does add real value by specifying that the id comes from list_assignments. It adds nothing about type, valid range, or behavior on an invalid/unenrolled 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?

The description names a specific resource pair ('submission/grading status') scoped to 'one assignment', which is enough for an agent to distinguish it from siblings like list_assignments or upcoming_deadlines. The verb is only implied ('status of'), so it reads more like a noun phrase than an action, but the intent 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 parenthetical '(use the assignid from list_assignments)' gives an explicit prerequisite and routes the agent to the correct sibling for obtaining the argument, which is genuinely actionable workflow guidance. It stops short of stating when to prefer this over other status-like tools or what happens for an ungraded/missing submission, so it is not a full when/when-not treatment.

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 supplied, the description carries the full burden; it does disclose ordering ('soonest first') and timezone semantics, which are genuinely useful behavioral facts. However, it leaves a meaningful ambiguity: whether already-overdue or undated assignments are included in the window, and there is no note on result size or limits.

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

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

One tight sentence with the core predicate front-loaded, followed by the two behavioral qualifiers (ordering, timezone). No wasted words.

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, and with one optional parameter the definition is nearly sufficient. The remaining gap is the treatment of overdue items and window boundaries, which matters for an agent deciding whether this call is enough.

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: 'within the next `days` days' defines exactly what the single parameter means. It does not restate the default of 14, but the semantic meaning is fully conveyed.

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 ('Assignments due within the next `days` days') with clear scope, and the sort order ('soonest first') and timezone handling are stated. It implicitly distinguishes itself from list_assignments by adding a due-window filter, though it never names that 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?

The use case (deadline triage within a horizon) is strongly implied by the wording, but there is no explicit when-to-use / when-not guidance and no reference to list_assignments as the unfiltered alternative. An agent can infer the intent but must guess the boundary between this tool and the general assignment lister.

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