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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond them by disclosing that the call performs a login/credential validation, not just a read, which is a behavioral trait the annotations do not convey.

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 that states the action and the returned data with no filler. Nothing is wasted or buried.

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 an output schema present, the description need not explain return values in detail, and annotations cover the safety profile. The only gap is routing guidance versus the sibling status tool, which is minor for a zero-parameter connectivity check.

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 and schema coverage is 100%, so the baseline of 4 applies; there are no parameter semantics to clarify or omit.

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+resource: verifying mailbox login and returning inbox total and unread counts. It is clear what the tool does, but it does not distinguish itself from the sibling school_mail_status, which likely overlaps in reporting mailbox state.

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 a connectivity/auth check to run before other mail operations — but no explicit when-to-use guidance or reference to alternatives like school_mail_status is 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 declare readOnlyHint=false but destructiveHint=false and idempotentHint=false, leaving the nature of the write ambiguous. The description resolves this by clarifying that it writes a local file while leaving mailbox content unchanged, which is valuable disambiguation beyond the annotations. It does not cover overwrite behavior or permissions.

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 the action and destination front-loaded, followed by the part_index source and the mailbox-unchanged caveat. No filler, though it could be marginally tighter.

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 returned path need not be explained in prose. Combined with annotations covering the safety profile and the description covering the write scope and part_index origin, the definition is nearly complete; only the target directory rules and overwrite semantics 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 description coverage is 0% across 4 parameters, so the description must compensate. It meaningfully explains the non-obvious part_index (sourced from the mail's attachment list), but uid, uid_validity, and mailbox remain undocumented; uid_validity in particular is an IMAP-specific value an agent may not infer.

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: save the specified mail attachment to the project's local private directory and return the path. This is clearly distinct from the read/search/list siblings, though it does not explicitly name them. The scope of the operation (local save, not mailbox change) 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 implies a workflow prerequisite by stating that part_index comes from the attachment list obtained when reading the mail, which is useful context. However, there is no explicit when-to-use vs alternatives guidance or statement of when this tool should not be chosen over school_mail_read.

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, idempotentHint, destructiveHint=false, and openWorldHint, covering the safety profile. The description adds behavioral detail about the output content—that it includes Chinese folders and whether they can be opened—which is useful context beyond the annotations, though it does not discuss authentication or rate 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 sentence that front-loads the core action ('list school mailbox folders') and appends only relevant scope detail. Every element earns its place, with no redundant or filler text.

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 zero parameters, an output schema present, and rich annotations, the description need only state what is listed. It does that and adds a useful return-content nuance, though it omits any guidance about when listing folders is preferable to other mail operations.

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. There are no parameters for the description to clarify, and the schema is effectively complete for an empty argument 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 resource: '列出学校邮箱文件夹' (list school mailbox folders), with additional scope about Chinese folders and whether they can be opened. No sibling tool (search, read, download_attachment, status, etc.) lists folders, so the agent can distinguish it immediately from the name and description 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 usage by clearly identifying a listing operation, but it gives no explicit when-to-use or when-not-to-use guidance relative to siblings. For a zero-parameter listing tool, the intended use is largely self-evident, so this is minimum viable rather than absent.

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 readOnly/idempotent/non-destructive, but the description adds non-obvious behavior: it does NOT mark mail as read (unusual for a read tool) and warns that body and attachments are untrusted external data. It omits truncation behavior implied by max_chars, so not a full 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?

Three compact sentences, front-loaded with the action and the key non-obvious fact (not marking read), then prerequisites, then the safety warning. 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 an output schema present, return values need not be explained, and the description covers purpose, sourcing of required params, size limit, and a security caveat. The only real gap is the undocumented mailbox parameter.

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 explains uid and uid_validity (sourced from search) and the max_chars range 1–100000, but the mailbox parameter and its INBOX default are never mentioned, leaving one of four parameters undocumented anywhere.

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: reading email body and attachment listing, and explicitly notes it does not mark messages read. It implicitly separates itself from siblings by explaining uid/uid_validity originate from search results, so an agent can route between search, read, and download_attachment.

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 usage prerequisite — uid and uid_validity must come from search results — which effectively routes the agent to school_mail_search first. It does not, however, state explicit when-not-to-use conditions or compare directly against download_attachment.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavior beyond them: results are sorted by UID descending, and since is inclusive while before is exclusive. It says nothing about pagination behavior or result size caps, which keeps it short of 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?

A single dense sentence-block that leads with what the tool does and what it returns, then packs ordering, numeric bounds, date semantics and filters with no filler. Every clause maps to a parameter or a return behavior.

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 an output schema present, the description correctly need not detail return values, and annotations already carry the safety profile. What remains missing for a 9-parameter search tool is offset/pagination and mailbox-scope semantics, which are absent from both the description and the schema.

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 carries the full burden and does compensate for most of it: limit range 1–50, YYYY-MM-DD date format, since-inclusive/before-exclusive semantics, and the mapping of unread/sender/subject/text filters to parameters. offset and mailbox are left unexplained, so it is substantive but not complete.

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 ('搜索邮件') plus what it returns ('摘要和 UID'), which separates it from siblings like school_mail_read or school_mail_status. It does not, however, explicitly name the sibling that handles full-message retrieval, so the differentiation is inferable 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?

The list of available filters (unread, sender, subject, full text) implies when to reach for this tool, but there is no explicit 'use this instead of X' routing or stated prerequisite. Usage must be inferred from the filter surface rather than read directly.

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 readOnly, idempotent, non-destructive and offline (openWorldHint=false). The description still adds meaningful behavior beyond that: no popups, no authorization created, and critically no password is received or handled – real trust/safety information for a mail setup tool. It stops short of describing how the steps are delivered (return format), hence 4 rather than 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?

A single compact sentence front-loads the trigger condition, then enumerates the safety constraints after a semicolon. There is no filler and no repetition of the tool name or 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?

With zero parameters and an output schema present, the description does not need to explain return values, and it covers usage trigger plus safety constraints. What remains thin is any hint of what the returned steps cover or that no network state is changed, but for a simple guide tool this is 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 takes zero parameters, so the baseline of 4 applies. The description correctly adds no parameter talk, which is appropriate for a no-arg guide 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?

The description gives a specific verb (返回/returns) and a concrete resource (本机操作步骤 – local machine setup steps), scoped to the school mail setup scenario. It is distinguishable from siblings like school_mail_check_connection because it returns guidance rather than performing a connection action, though it never names a 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?

The trigger conditions are stated precisely: use it on first setup (首次接入) or when the connection has failed (连接失效). That is a clear contextual 'when' with no ambiguity. It does not name an explicit alternative or a when-not case, so it falls short of 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?

The annotations already establish a safe, idempotent, read-only operation, but the description adds real value with two non-obvious behavioral facts: it is purely local (no network) and it will not echo credentials. There is mild tension between 'no network' and openWorldHint=true, and no mention of what 'ready' means or how failures are reported; with annotations covering the safety profile, 3 fits.

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, front-loaded with the action, followed by two boundary clauses. Every fragment earns its place with zero 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 zero-parameter status tool with an output schema covering return values, the description supplies the essentials: scope, locality, and credential safety. It would be complete at 5 if it clarified what constitutes 'ready' or pointed to school_mail_setup_guide when configuration is not ready.

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 and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless 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?

The description names a specific check ('check local mailbox configuration readiness') with a clear resource, and the 'no network' clause implicitly separates it from school_mail_check_connection. It stops short of naming that sibling explicitly, so differentiation is inferred 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?

'Does not connect to network' suggests this is the pre-flight/diagnostic step to run before school_mail_check_connection, but the description never states when to call it, when not to, or what to do on failure (e.g., hand off to school_mail_setup_guide). Usage is implied only.

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