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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds real value beyond that: the message lands in Drafts rather than being delivered, the return is draft_id + preview, and replies get threading headers (In-Reply-To/References) and inherited recipients. It does not mention that repeated calls create separate drafts, though the non-idempotent annotation already signals that.

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 core action and its non-sending nature are front-loaded in the first clause, with the reply/forward specifics in a compact second sentence. The parenthetical Chinese folder name is a minor extra but earns its place for locale-aware matching.

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 13-parameter, zero-required tool with no output schema, the description covers the essential behavior and return value (draft_id + preview) and explains the two non-obvious parameter clusters. Attachment restrictions and account defaults live in the schema, so nothing critical is missing.

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 85%, so the baseline is 3, but the description goes further by explaining what reply_to_id and forward_id actually trigger: Re: subject, threading headers, recipients pulled from the original, and forward modes. That is meaning the schema's short param descriptions do not carry.

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 an email to Drafts') plus the crucial scope qualifier 'without sending', which cleanly separates it from the send_email sibling. It also enumerates the two composition modes (reply, forward) so the agent knows the tool's full surface.

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?

Clearly indicates the use case — when the user should review before sending — and the reply/forward conditions that select the respective parameters. It never explicitly names send_email as the alternative for immediate delivery, so routing is implied rather than stated.

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?

Goes well beyond the bare readOnlyHint: never overwrites or follows symlinks, sanitized names, mode 0600, macOS quarantine / Windows Zone.Identifier marking, and a hard 50 MB ceiling. The only tension is that a tool which writes a file and sets quarantine attributes does mutate the local environment, so readOnlyHint should be read as 'does not change mailbox state' — worth clarifying rather than contradicting outright.

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 that front-loads the action and destination, then lists guarantees and the return payload in one more clause. No filler and nothing repeated from the schema verbatim.

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 fully documents the return value (path, size, sha256, content_type, text excerpt for text/csv/json/md), which is exactly what an agent needs to chain calls. Remaining gaps are failure semantics: what error a >50 MB attachment produces, and what happens when both index and filename are omitted.

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 100%, so the parameters are already documented; the description still adds value by naming the NETEASE_MAIL_DOWNLOAD_DIR root that dest_dir is resolved against and by implying the 'or' relationship between index and filename. It does not restate the 'anything outside is refused' rule, but the schema covers 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+resource ('Save one attachment') plus the exact destination root (NETEASE_MAIL_DOWNLOAD_DIR). No sibling tool writes files, and 'attachment' plus the 'index from read_message' hint make its place in the workflow 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?

Usage is only implied: the schema note that 'index' comes from read_message signals the read_message -> download_attachment flow, but the description itself never says when to use this versus just reading the message body or when not to use it. An agent can infer the sequence but gets no explicit 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 the description adds useful behavioral detail beyond that: it reconstructs across folder/INBOX/Sent, uses Message-ID/In-Reply-To/References with subject fallback, returns chronological results, and includes snippets. It does not discuss limits or output shape beyond snippets, but it adds meaningful 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?

The description is two compact sentences with the core action and scope front-loaded. Every phrase contributes useful information about scope, threading mechanism, fallback, ordering, and snippet output.

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 read-only tool with full schema coverage and no output schema, the description is largely complete: it explains what is reconstructed, how threading is determined, and that results are chronological with snippets. Minor gaps remain around output detail and limits, but the essential call context is present.

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 100%, so both parameters are already documented. The description clarifies that the id can be any message in the conversation, but adds no additional parameter syntax or constraints 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?

The description uses a specific verb, "Reconstruct," and resource, "the conversation around a message," and clarifies the scope across folder, INBOX, and Sent. It distinguishes itself implicitly from single-message tools like read_message by emphasizing conversation reconstruction, but it does not explicitly name 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?

The usage is implied: use this to reconstruct a conversation around a message. However, the description gives no explicit when-to-use guidance, exclusions, or alternatives such as read_message for a single message or search_messages for discovery.

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 openWorldHint=false, and the description adds real context beyond them: check=true performs a login against the mail service and returns INBOX counts, and the 授权码 value is only reported as a stored/not-stored flag rather than exposed. It doesn't say what a failed login looks like or whether check has side effects on the account, which keeps it below 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 short sentences; the base listing and its returned fields come first, and the opt-in flag behavior follows. Every clause carries information and nothing is repeated from the schema or annotations.

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 enumerates what is returned, including the conditional INBOX counts with check. It's nearly complete for a single-flag read tool; only ordering/shape of the account list and error behavior are unstated.

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 sole parameter has no description, so the description must carry it — and it does, explaining exactly what check=true adds over the default and that the default omits login and INBOX counts. Only the cost/behavior on partial failure is left implicit.

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?

Specific verb ('List') plus a precise resource ('configured NetEase accounts') and an enumeration of the fields returned: default account, mode (readonly/draft/full), and whether a 授权码 is stored. No sibling tool lists accounts, and the description makes that scope 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?

It clearly states the condition that selects the expensive behavior: 'check=true also logs in and reports INBOX counts', so an agent knows when to opt in versus take the cheap default. It doesn't name trade-offs or exclusions (e.g. latency/credential-failure behavior) but there is no sibling alternative to route to.

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 annotation already establishes that this is a safe read operation. The description adds relevant context about what folder data is returned and what with_counts adds, but does not mention permissions, pagination, or other behavioral details.

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 short and front-loaded, starting with 'List folders' and then adding the optional count behavior. Every sentence contributes useful information without repetition.

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 read-only tool with two parameters and no output schema, the description explains the main returned fields and the optional count behavior. It is nearly complete, with the only notable gap being no guidance on when to choose this tool over siblings.

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 schema documents the account parameter, while the description fills in the otherwise undocumented with_counts parameter by explaining that it adds message/unseen counts. Together this covers both parameters well, though the description itself does not mention account.

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 folders.' It also clarifies the returned folder representation (decoded names, raw IMAP names, special-use role), making the purpose clear. It does not explicitly differentiate itself from siblings, but the resource type is distinct.

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?

Provides no explicit guidance on when to use this tool versus alternatives such as list_accounts or search_messages. The only usage-like detail is the parameter behavior for with_counts, not tool selection.

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 description adds substantial context beyond the annotations: which actions are immediate and reversible, which require preview plus human approval via elicitation or confirmation_token, and that trash moves messages to 已删除 without permanent deletion. This materially clarifies safety and workflow behavior for a destructiveHint=true 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?

Three sentences, front-loaded with the core actions, followed by operational details. Every sentence adds useful information without repetition or 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 multi-action mutation tool with no output schema, the description covers the necessary operational context: action set, batch limit, immediate versus two-phase behavior, approval mechanism, and trash semantics. No critical invocation detail appears missing.

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 50%, and the description adds useful meaning for ids (≤50), action behavior, and confirmation_token's role in the two-phase flow. target_folder is only implicitly covered via the move action, so it does not fully compensate for every parameter 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 specific verbs (move, trash, mark read/unread, flag/unflag) and the resource (up to 50 messages), making the tool's operation clear. It does not explicitly differentiate itself from siblings such as search_messages or read_message, 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?

It clearly explains that mark/flag actions run immediately while move/trash require a two-phase preview and human approval. This gives useful action-level usage context, though it does not explicitly state when to choose this tool over sibling tools like search_messages or get_thread.

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 description is otherwise informative about return shape and conditional side effects, but it discloses that mark_read=true marks the message read. That optional mutation contradicts the annotation readOnlyHint=true, which declares the tool read-only.

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 front-loaded with the core action and then compactly lists output details and the mark_read condition. It is appropriately sized with no wasted sentences.

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 usefully explains the return payload: headers, text body conversion, attachment metadata, and flags. It is nearly complete, but it omits interactions such as max_chars/include_html and the mode prerequisite noted in the schema for mark_read.

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 75%, and the schema already documents id, mark_read, and max_chars. The description adds useful meaning about HTML-to-text body handling and the attachment list, but it does not clarify include_html or max_chars interactions 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?

It states a specific verb and resource, "Read one message," and enumerates the returned payload: headers, body, attachment list, and flags. It does not explicitly distinguish itself from siblings such as get_thread or search_messages, so it is clear but not fully differentiated.

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 "Read one message" and the conditional note about mark_read=true. However, it gives no explicit when-to-use guidance or alternatives, such as using get_thread for a conversation or search_messages to locate a message.

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?

Beyond the readOnlyHint annotation, the description discloses important behavior: returned fields, newest-first ordering, server-side date/unread/flagged filtering, local header matching over max_scan candidates, truncation semantics, and the fact that message bodies are never searched. These details materially affect how an agent should invoke and interpret the 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?

The description is compact and front-loaded: purpose first, then return shape, filtering mechanics, truncation, and the body-search limitation. Every sentence adds useful information without 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?

Given 13 parameters and no output schema, the description is largely complete: it states the return fields and explains the key filtering and truncation behavior. Minor details such as folder defaults and account handling are left to the schema, which is reasonable given the high schema coverage.

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 high at 92%, so the schema already documents most parameters. The description still adds cross-parameter meaning by explaining which filters run server-side, which run locally over max_scan, and why truncated results may occur.

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 and resource: "Search or list messages" and specifies newest-first ordering. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as read_message or list_folders.

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 "Search or list messages" and the note that bodies are never searched, but the description does not explicitly say when to use this tool versus alternatives like read_message or get_thread. The server-side versus local filtering distinction helps, but is not framed as usage guidance.

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?

Adds rich behavior beyond annotations: the elicitation/preview flow, the confirmation_token requirement, and the rule that any change to recipients/subject/body/attachments causes rejection. This tells the agent exactly how the destructive send is gated, which annotations alone 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?

Three tightly packed sentences, front-loaded with purpose then the two-phase protocol. No filler; each clause conveys actionable constraint.

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 critical send-safety workflow is complete, but with 16 params, no output schema, and a sparse preview description ("full preview" unexplained), the definition leaves gaps around the reply/forward parameter family and what the preview 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?

With 16 parameters at 38% schema coverage, the description should carry the load, but it only says "same arguments as create_draft." It never clarifies reply_to_id/reply_all, forward_id/forward_mode, quote_original, or delete_draft_after_send, leaving the majority of params undocumented in both schema and description.

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 ("Send an email via SMTP") and immediately distinguishes the two modes (compose with create_draft's arguments, or draft_id). It also names the sibling create_draft, so an agent can route correctly.

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?

Explicitly explains the two-phase call protocol: first call returns a preview/elicitation, second call uses confirmation_token only after explicit user approval. It lacks a crisp "use create_draft instead when you only want to save," but the reference to create_draft and the approval flow give strong usage context.

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 declare readOnlyHint, so the description carries most of the burden and does well: it discloses the blocking wait, the transport strategy (IDLE when available, else polling), and what the response contains (summary plus extracted `codes`). It stops short of saying what happens when the timeout expires with no match, which matters for a call that can block up to 600s.

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, both front-loaded: the scope constraint leads, then the return shape and mechanism. No filler, and the example use case is packed into a clause rather than a paragraph.

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 eight parameters and no output schema, the description compensates by naming the return payload (summary plus `codes`), which is exactly the missing structured info. The only real gap is undefined timeout/no-match behavior, which an agent would want before committing to a 120s default wait.

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 88%, so the schema already documents from/query/subject matching semantics, poll_s, account, timeout_s, and lookback_s in detail. The description only restates 'matching from/subject/query' and adds no filtering nuance of its own; baseline 3 applies when the schema does the heavy lifting.

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 plus a critical scope constraint: it waits for a NEW message arriving after the call starts, with an example use case (sign-up verification email). That scope sentence is what functionally separates it from search_messages, so an agent can pick correctly without opening either 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?

Gives clear context for when this is the right tool ('e.g. a sign-up verification email') and the 'arriving after the call starts' framing implicitly rules out using it to find existing mail. It never names search_messages or read_message as the alternative for already-delivered messages, and there are no explicit exclusions.

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