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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the base64 output format, the 2 MiB size cap, and rejection of executables, zip, and eml files, which are important constraints. It does not list every allowed type or describe error responses, but the core behavior is 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?

Two short sentences front-load the core action and then add constraints without filler or repetition of schema content. Every word contributes useful information.

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 description covers output format, size limits, and rejected types, but with no annotations and no output schema, it leaves the source of uid unstated and does not enumerate the allowlisted types. The definition is close but has clear gaps for a tool with moderate parameter complexity.

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 description adds no parameter-level meaning beyond the schema. The schema documents part, folder, and account_id, but uid is left unexplained in both the schema and the description, leaving a real gap at 75% schema description coverage.

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 opens with a specific verb and resource: 'Download one attachment as base64.' This clearly states what the tool does and its output format, distinguishing it from siblings like list_attachments and get_message without needing to inspect 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?

The phrasing 'Download one attachment' makes it clear this tool is for retrieving attachment content, while siblings like list_attachments are for listing attachments. The usage context is unambiguous even though it does not explicitly name alternative tools.

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?

Discloses important behaviors: sanitized output, wrapping in <untrusted-email>, BODY.PEEK to avoid marking as read, and blocking security/OTP mail. No annotations exist, so the description carries the burden well, though edge cases like errors are not mentioned.

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?

Concise and front-loaded with the core purpose. The final sentence about security/OTP is slightly ambiguous but does not bloat the description.

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 sibling tools and output-less schema, the description gives enough operational context: what is returned, safety handling, and key restrictions. It does not specify attachment behavior, but that is reasonably left to get_attachment.

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 descriptions fully cover the three parameters with useful provenance (uid from search_messages, folder default, account_id from list_accounts). The tool description itself adds no extra parameter meaning, so baseline 3 applies.

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?

Clearly states the tool reads one message as sanitized text, distinguishing it from attachment retrieval or search operations. The verb 'Read' and resource 'one message' are explicit.

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?

Mentions BODY.PEEK and security/OTP blocking, giving some usage context, but does not explicitly contrast with sibling tools like get_attachment or search_messages. The guidance is implicit rather than direct.

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 provided, the description carries the behavioral burden. It communicates a read-only intent ('查看'), excludes secrets from the response, and warns against modifying the repository. It does not explicitly state absence of side effects or error behavior, but for a zero-parameter getter the disclosed behavior is sufficient.

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-load the core purpose, then add ordering guidance and sibling routing without redundant filler. Every sentence contributes distinct information.

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 no-parameter getter with no output schema, the description is complete: it states the return scope (current mode and send whitelist), the non-secret nature, when to call it first, and how to perform related operations. No critical context 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?

The input schema has zero parameters, so there is nothing for the description to clarify at the parameter level. The baseline of 4 applies, and the description does not introduce any conflicting or misleading parameter behavior.

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 opens with the specific action '查看当前档位（read/draft/send）和发送白名单', naming the exact resource and its scope. It also clarifies what the tool does NOT return ('不含密钥'), which removes ambiguity and distinguishes it from other settings-related tools.

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 explicit when-to-use guidance ('每个新任务应先调用') and routes related actions to siblings (add_mailbox, unbind_mailbox). It omits an explicit reference to set_settings as the counterpart for changing settings, so the distinction from all siblings is not fully closed.

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 discloses that the tool does not return secret keys and explicitly warns not to modify the repository or MCP startup command, reinforcing a read-only safety profile. It does not mention output format or error behavior, but this is acceptable for a simple list 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?

The description is compact and front-loaded with the core purpose, then gives workflow, alternatives, and a safety caution. Every sentence earns its place without redundancy 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 zero-parameter, no-output-schema tool, the description covers purpose, safety, workflow, and alternatives. It implies that returned mailbox entries have an account_id usable by later tools, though it does not explicitly state the return shape. This is a minor gap rather than a blocking one.

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 there is nothing for the description to explain about individual inputs. The mention of account_id in downstream tools provides useful context about how the result relates to future calls, which adds value beyond the empty 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 ('列出' / list) and a specific resource ('已绑定邮箱' / bound mailboxes), and adds the clarifying constraint that keys are not included. This clearly distinguishes it from sibling tools like list_attachments and 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?

The description gives explicit workflow guidance: new tasks should first call get_settings, and when multiple mailboxes exist, subsequent tools should pass account_id. It also explicitly routes add operations to add_mailbox and unbind operations to unbind_mailbox, leaving no ambiguity about when to use alternatives.

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 bears the burden of disclosing side effects and permissions. It discloses that no bytes are returned, but does not explicitly state that the operation is read-only or has no side effects. A listing is presumed safe, but the transparency is partial.

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 concise sentences. It includes only essential information, with no redundancy or filler, and front-loads the core purpose.

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 description sufficiently conveys that it returns metadata about attachments and excludes content. Combined with the sibling list, an agent can infer the appropriate use case. It does not specify the return format (e.g., an array of objects), but this is a minor gap given the clarity of the listing intent.

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 provides descriptions for folder and account_id, but uid lacks a description, covering only 67% of parameters. The tool description adds no additional parameter context. The parameter names are self-explanatory, but the incomplete coverage keeps this at a moderate score.

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 explicitly states what the tool does: 'List attachment names, types, sizes, and MIME part ids.' It also clarifies it does not return bytes, making the purpose unmistakable and distinguishing it from attachment retrieval.

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 statement 'Does not return bytes' implicitly guides the agent to use a different tool (e.g., get_attachment) when actual content is needed. While it doesn't name the sibling tool explicitly, the conditional guidance is clear enough for typical usage.

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 provided, the description carries the full burden. It does add the useful scope 'for one mailbox' and the verb 'List' implies a non-destructive read operation. However, it does not disclose return format, whether all folder types are included, or how the optional account_id affects behavior beyond what the schema states.

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 one short, direct sentence with no filler. The core action and scope are immediately clear, which is ideal for such a simple 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?

For a simple list tool, the description plus schema are mostly sufficient, but there is no mention of output shape or what happens when multiple mailboxes are linked and account_id is omitted. The absence of annotations and output schema raises the completeness bar, so a mid-range score is appropriate.

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%, and the account_id parameter already has a clear description including when to omit it. The tool description adds no additional meaning about parameters, so the baseline of 3 applies.

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 ('List IMAP folders') and scopes it to one mailbox, which clearly differentiates it from sibling tools like list_accounts and list_attachments. Even without naming alternatives, an agent can tell what this tool does.

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 guidance about when to use this tool versus alternatives or when to omit or provide the account_id. The schema hints at usage by saying 'omit when only one mailbox is linked,' but the description itself provides no context or exclusions.

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 provided, the description carries the full burden of explaining side effects. It clearly states that it saves a draft and does not send, and notes the sender is the linked account. It does not mention return values or error behavior, but the core effect is 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?

The description is extremely concise, using two short sentences. It contains no redundant information and is well-structured, making it easy for an agent to parse.

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 save operation, the description provides sufficient context: it saves a draft, does not send, and specifies the sender. It omits return values or potential error conditions, but that is not critical for a straightforward operation. Overall, it is complete enough for an agent to understand the tool's role.

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?

Only 2 out of 5 parameters (to, account_id) have schema descriptions. The tool description itself adds some context about the sender (linked account) but does not elaborate on subject, body, or cc. Given the low schema coverage, the description does not fully compensate, though the parameter names are self-explanatory.

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 clearly states that it saves a new message in the IMAP Drafts folder and explicitly distinguishes itself from reply drafts and sending operations. It also clarifies that the sender is the linked account, which is specific and 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 explains that it does not send, which helps differentiate it from send_draft. It also specifies that the message is a new one (not a reply), distinguishing it from save_reply_draft. However, it does not explicitly state when to use this tool versus alternatives, though the wording strongly implies it.

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 disclosure burden and does reveal key behavioral traits: recipients are taken from original headers rather than body text, and security/OTP messages are refused. It does not mention side effects such as where the draft is stored or whether it overwrites an existing draft, but the disclosed behavior is genuinely useful and non-obvious.

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 short sentences with no filler. The core purpose is front-loaded, and the behavioral warnings are stated compactly and clearly.

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 description captures the most important behavioral rule but leaves several contextual gaps: it does not explain what uid refers to, how reply_all alters behavior, what happens after saving, or what output is returned. With no output schema and low parameter coverage, this is only minimally 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 only 40%, so the description should compensate for the undocumented uid, body, and reply_all parameters. It only tangentially clarifies that body text is not used for recipients, leaving the meaning of uid and the effect of reply_all underspecified.

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 clearly states the tool saves a reply draft, with a specific verb and resource. It adds important clarifying behavior—recipients come from the original Reply-To/From, not body text—that helps distinguish it from a generic draft tool, though it does not explicitly name sibling alternatives.

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 the intended use case (saving a reply draft) and notes when it will refuse to act (security/OTP messages). However, it gives no explicit guidance on when to use this tool instead of siblings like save_draft, send_reply, or send_draft.

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 disclosure burden and covers the key behavioral constraints: Security/OTP subjects are redacted, bodies are never returned, and email content is untrusted. It doesn't mention pagination, sorting, or exact metadata fields, but the disclosed constraints are non-obvious and valuable.

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 short sentences with the core scope front-loaded: 'Search one folder.' Every clause adds distinct information—folder scope, metadata-only results, redaction, and content safety—with no fluff or 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 tool with no annotations, no output schema, and nine optional parameters, the description covers the crucial result constraints but leaves gaps: exact envelope fields, search-criteria combination semantics, and how to choose between this and sibling message tools. It is adequate but not fully self-sufficient.

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 description adds no parameter-level meaning beyond what the schema already provides. Parameters like to, unseen, and subject lack schema descriptions, and the description doesn't clarify their matching behavior or how criteria combine. With 67% schema coverage, some compensation was expected, but none is present.

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 one folder.' It immediately differentiates from get_message by saying 'Returns envelope metadata only' and 'bodies are never returned,' making the tool's role unmistakable among the sibling email tools.

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 provides clear context: use this for folder-scoped searches with metadata-only results, and it explicitly warns that bodies are never returned. It doesn't name an alternative tool outright, but the exclusion boundary is evident enough for an agent to avoid using it for message content retrieval.

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?

Discloses the two-phase prepare/send behavior and confirmation token, but with no annotations it does not state irreversible delivery, required permissions, or what side effects the first call has.

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 concise sentences with no filler; the action and sequence are front-loaded and easy to parse.

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?

Provides sufficient context for the two-step flow and mentions the preview and confirm_token return. It lacks detail about the second call's return value or error cases, but remains adequate for the tool's purpose.

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?

uid and account_id have basic schema descriptions, and confirm_token is explained as being returned from the first call. However, confirm_token has no schema description and no parameter is marked required, though it is logically required for the send step.

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?

Clearly identifies the tool as preparing or SMTP-sending a Drafts UID, which distinguishes it from sibling send tools like send_email, send_reply, send_forward, and save_draft.

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?

Describes the two-call workflow explicitly and mentions the need for user agreement and confirm_token. It does not explicitly contrast with sibling send tools, but the procedure is clear enough.

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?

While no annotations are present, the description discloses the two-phase behavior (no SMTP on first call, send on second) and the allowlist restriction. It implies a write operation through 'SMTP-send' but does not explicitly mention side effects like email delivery or state changes, so a small gap remains.

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 concise, composed of two sentences that efficiently convey the tool's purpose, usage flow, and key constraints. No unnecessary words or 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 the tool's complexity (two-step flow, allowlist, recipient restriction), the description covers the essential context. It does not mention error handling, rate limits, or attachment behavior, but these are not critical for basic invocation and the tool has no output schema to explain, so it is reasonably 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 description clarifies three of six parameters (to, account_id, confirm_token) with contextual details, but body and subject have no additional explanation. Since schema coverage is 50%, the description adds some value but leaves half the parameters underexplained.

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 clearly states the tool's dual-purpose: preparing a preview and sending a new message. It uses specific verbs 'Prepare' and 'SMTP-send' and distinguishes itself from sibling tools like send_draft or send_reply by focusing on new messages.

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 provides a clear two-step usage pattern: first call returns preview + confirm_token, second call sends with only confirm_token. Also mentions the allowlist requirement and warns against extracting recipients from email bodies, giving practical 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?

With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains the stateful two-call protocol, preview + confirm_token on the first call, and the requirement to call again with the token. It also warns that the 'to' field must not be sourced from the original email body, which is useful security-relevant behavior.

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: the core action appears first, followed by the critical two-step protocol and the security constraint. Every sentence contributes meaningful information, with no filler or repetition beyond the already-schema-covered 'to' rule.

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 tool has seven parameters, no output schema, and no annotations, so the description should do more to make the tool fully self-contained. It covers the confirm flow well, but does not explain what the preview contains, how uid selects the original message, whether cc requires allowlisting, or what error conditions look like.

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 low at 43%, so the description needs to compensate. It does explain confirm_token's role in the two-step flow and reinforces the 'to' constraint, but it leaves cc, uid, and comment semantics largely to inference from parameter names and sibling tool conventions.

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 clearly identifies the action ('Prepare or SMTP-send a forward') and resource ('a forward'), distinguishing it from reply, draft, and direct email siblings. It also explains the two-phase prepare/send behavior, leaving no ambiguity about what the tool does.

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 provides clear context for when and how to use the tool: first call to prepare and obtain a confirm_token, second call after user agreement to send. It does not explicitly name alternatives like send_reply or send_email, but the 'forward' resource is sufficiently distinct that the tool selection intent is clear.

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 provided, the description carries the transparency burden. It discloses the confirmation flow, the fact that a later call actually sends, and that To is locked to the original Reply-To/From. It does not mention whether the first call has side effects, but the core behavioral safety information is present.

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 concise sentences deliver the essential workflow and constraints with no filler. The action is front-loaded, followed by the confirmation sequence and the To-lock caveat.

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 two-step confirmation behavior is covered, and the tool is usable as described. However, there is no output schema and the description does not mention the preview's contents, error/failure behavior, or how this relates to save_reply_draft/send_draft, leaving some gaps for an agent to infer.

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 only 33%, so the description must compensate. It does clarify confirm_token's role in the two-step flow and implies uid/body relate to the original message and reply content, but reply_all and account_id remain under-explained.

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 clearly identifies the action as preparing or SMTP-sending a reply and highlights the locked To field, which distinguishes it from siblings like send_email, send_forward, and save_draft. The two-phase nature is also stated upfront.

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 explicitly explains the required two-call workflow: first call gets a preview and confirm_token, second call with the token sends. It does not explicitly contrast with send_email/save_reply_draft, but the reply-specific context and confirmation gate give clear when-to-use 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?

With no annotations provided, the description carries the burden and does disclose important behavioral traits: enabling send affects all Bots under the account, confirmation cards are required for send and allow_sensitive, and authorization codes must not be written into the tool. It stops short of explaining persistence, reversibility, or the confirmation-card return flow, and '打开草稿' is somewhat ambiguous.

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-loads the main purpose, then gives mode-specific conditions, a security warning, and scope. Every sentence adds useful information, though terms like '档位' and '打开草稿' reduce precision and clarity.

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 three-parameter tool, the description covers core modes, prerequisites, security, and scope, which is fairly complete. However, it omits the mode=read case, does not explain the confirmation-card flow or return behavior, and does not route the agent to sibling tools like get_settings when read-only access is needed.

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 baseline is 3, but the description adds conditional semantics beyond the schema: mode=send requires send_allowlist plus confirmation, and allow_sensitive requires confirmation. It explains mode=draft behavior, though mode=read is never addressed and send_allowlist syntax is correctly left to 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 states a clear action ('修改' / modify) and targets ('档位' or mode, and send allowlist), and it is clearly tied to the set_settings resource rather than get_settings. However, '档位' is an ambiguous way to refer to the 'mode' parameter, and '在用户选定后' adds context without explaining what selection means.

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 gives explicit conditional usage rules: mode=draft opens draft mode, mode=send requires send_allowlist and a confirmation card, and allow_sensitive also requires confirmation. It does not mention alternatives or when-not-to-use conditions, but the mode-specific guidance is clear 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 of behavioral disclosure. It explicitly states that unbinding does not delete emails on the server, which is the key side-effect an agent needs to know. It also implies the operation is local to the MCP connection via the schema's 'Unbinds this MCP only' note, though that phrasing appears in the schema rather than the description. Overall, this is a simple operation and the main behavioral trait is disclosed.

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 extremely concise: two short sentences that lead with the primary action and immediately follow with the critical caveat about not deleting server emails. There is no redundant or filler content, and 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?

For a simple tool with one parameter, no output schema, and a straightforward operation, the description covers what the action is and its key non-destructive effect. The essential context (unbind local connection, preserve server data) is present, and no additional return-value or error-handling details are necessary for an agent to invoke it correctly.

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 the single parameter `account_id` is already fully documented with its source and behavioral implications. The description does not add any additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 ('解绑' / unbind) and resource ('邮箱' / mailbox), clearly indicating the action. It also adds a clarifying scope note that server messages are not deleted, which distinguishes it from any deletion-oriented operation. However, it doesn't explicitly contrast with sibling tools, though none of the siblings appear to perform a similar unbinding action.

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 the tool is used to unbind a connected mailbox, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. The input schema mentions 'Account id from list_accounts,' which is a prerequisite, but this guidance is not present in the description itself, leaving some inference to the agent.

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