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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the tool surfaces body content, attachments, and submission status, which tells the agent what to expect back, but says nothing about permissions or whether enrollment/access checks apply.

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 with no filler, and the primary action is front-loaded. It is arguably too terse given the unexplained cmid, 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?

With no output schema and no annotation gaps, the main remaining burden is teaching the agent what cmid is and how it relates to modtype. One of two required parameters is undocumented, so the definition is minimally 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. It partially does by giving modtype example values (assign/resource/quiz), which is genuinely useful, but cmid is left completely unexplained — neither its meaning nor where to obtain it.

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 uses a specific verb (読む/read) with a clear resource (活動/activity) and enumerates what is returned: body, attachments, and submission status. This distinguishes it from siblings like moodle_course or moodle_deadlines, though it never names those siblings 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 tool versus moodle_course or moodle_download_file, nor any preconditions. Usage is only implied by the tool name and the modtype examples, leaving the agent to infer 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing further: no indication of whether a moodle_login session is required, how many announcements are returned, ordering, or pagination 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 short sentence with the scope constraint front-loaded and no filler. It is efficient, though the terseness edges toward under-specification rather than tightness.

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, no annotation detail beyond read-only, an undocumented parameter, and a likely login prerequisite implied by the sibling moodle_login, the description leaves too much for the agent to guess. It should at minimum say whether authentication is needed and what the response contains.

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 parameter 'Days' with a default of 30. The description does clarify that `days` is a lookback window into the recent past, which is genuine added meaning, but it doesn't state boundaries or format expectations beyond that.

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

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

States a specific verb and resource (お知らせを読む = read announcements) scoped to the last `days` days, which is clearly understandable. However, it never distinguishes itself from the sibling moodle_deadlines, which an agent could plausibly confuse with 'recent announcements'.

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, when-not-to-use, or alternative-tool guidance is given. The agent must infer from the name alone whether to call this or moodle_deadlines for time-sensitive course information.

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?

The readOnlyHint and destructiveHint annotations already declare this as a safe read operation, and the description's '読む' is consistent with that. However, it adds almost no behavioral detail beyond the annotations, such as result format, scope, or authentication requirements.

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 a single compact sentence with zero waste and front-loads the key action and result. It is appropriately sized for a one-parameter read-only tool.

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 the simple read-only nature, one required parameter, and absence of an output schema, the description is largely complete: it says to search by course name and read a list of materials/activities. It could optionally clarify the returned fields or matching behavior, but nothing critical is missing for invocation.

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 carry parameter meaning. It does so for the sole required parameter by stating that the query is a course-name search, which is sufficient for correct invocation even without additional match-format 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?

The description states a specific verb and resource: search by course name and read the list of materials/activities. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as moodle_activity or moodle_announcements.

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 'コース名で検索し' implies the tool is used for course-name lookup, but there is no explicit guidance on when to use it versus moodle_activity or other siblings, and no exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered and the description does not need to repeat it. It adds that results include submission status, which is useful return-shape context, but says nothing about auth prerequisites, ordering, or whether this covers all courses or only enrolled ones.

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. The purpose is stated first and the parameter explanation follows, so an agent gets the essentials in one pass.

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, so the description is the only source for what comes back, and it only says 'deadline list and submission status' without field detail. With one parameter and safety already covered by annotations, the definition is adequate to invoke the tool but thin on result expectations.

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 carry the single parameter — and it does, clarifying that days_overdue is how many days into the past to include, resolving the otherwise ambiguous name. It stops short of stating how 0 behaves or whether the value is clamped, which is a minor residual 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 names the two things returned: a deadline list and submission status. That is a clear resource statement an agent can act on. It lacks an explicit verb and does not differentiate from siblings, though the sibling set (login, course, announcements, activity, download_file) 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?

Usage is only implied: an agent can infer this is the tool for upcoming/past Moodle deadlines. There is no explicit statement of when to use it, what it excludes, or whether authentication via moodle_login must happen 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?

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds real value beyond them by stating '上書きしない' (does not overwrite), which pins down what happens to an existing file — a detail the annotations do not encode. It does not cover auth requirements, directory creation, or error behavior on failure.

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, front-loaded sentences with no filler — destination first, then the input requirement, then the overwrite caveat. Every sentence carries an actionable fact.

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 0% parameter coverage, the description covers purpose, inputs, and the non-overwrite behavior adequately. It stops short on what the call returns (a path? a confirmation?) and on any authentication or failure-mode context, which matters for a tool that writes to disk.

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 carry the load, and it does: it names the output destination, explains cmid and url, and adds a mutual-requirement rule ('one of the two') that the schema's anyOf plus single required field does not enforce. It still doesn't say what form cmid or url should take.

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 concrete verb and resource: saving course material to a local output path. No sibling tool (login, deadlines, course, announcements, activity) overlaps with file download, so sibling differentiation is implicitly satisfied, though the description never says so 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?

'cmid or url is required' is a parameter constraint, not usage guidance. There is no statement of when to reach for this tool versus the browsing siblings, and no prerequisite is mentioned (e.g. that a session/login must exist 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?

Annotations only say readOnlyHint=false and destructiveHint=false, which doesn't tell the agent much about this tool. The description adds the crucial behavior: it opens a UI window on the user's machine and blocks until the person logs in and closes the browser, plus the macOS ⌘Q caveat. What's missing is timeout/failure handling and whether the login persists for later calls.

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, then the wait semantics, then the platform-specific instruction. Every sentence carries information the agent or user needs.

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 parameters, no output schema and thin annotations, the description carries the burden well by explaining the interactive blocking flow and the user-facing instruction. It is slightly incomplete about what happens after the window closes (is the agent's session now authenticated, what if login fails).

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 and there is nothing for the description to disambiguate. Schema coverage is 100% for an empty object.

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 object (opens a login window on the user's PC) plus the wait condition, which clearly separates it from the sibling tools that all read Moodle data. It never names a sibling explicitly, so the differentiation is implicit rather than stated.

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

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

Usage is only implied: because the tool waits for a human to log in, an agent can infer it is the interactive prerequisite before the read-oriented siblings. The description never says when to call this instead of them, nor what to do if a session already exists or the user abandons the login.

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