mail-mcp

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

With no annotations, the description carries the full burden, and it does so reasonably: it discloses that nothing is dispatched, that the storage backend (IMAP/EWS/Graph) is auto-selected from configuration, and that a feature flag must be enabled. It omits details like error/permission behavior, but the safety-critical non-send fact is stated.

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 tightly written sentences, front-loaded with the action and immediately followed by the safety-critical caveat and the activation prerequisite. 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?

An output schema exists and all 11 parameters are documented, so return-value explanation is not needed. The description covers the operation, its side-effect boundary, and the enablement gate; only finer operational detail (e.g., failure modes) is absent, which is minor here.

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% with 11 well-documented parameters (including required 'to'/'subject' ranges and an attachment sub-schema), so the schema already does the heavy lifting. The description adds no parameter-level detail, matching the baseline for full schema 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?

States a specific verb and resource ('Save a new email as a draft in the account's Drafts folder') and immediately scopes it against the send operation with 'Nothing is sent.' An agent can distinguish it from siblings like draft_send and draft_update without opening any 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?

'Nothing is sent' clearly demarcates this from draft_send, and 'Save a new email' implies creation rather than draft_update. The prerequisite 'Requires MAIL_DRAFTS_ENABLED=true' is a genuine usage gate. It stops short of naming sibling tools explicitly, so it doesn't reach the top bar.

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 and does disclose real behavioral traits: the operation is restricted to drafts, it is gated behind a feature flag, and it requires an explicit confirmation flag. It stops short of stating irreversibility or what happens on a failed precondition, which matters for a destructive 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?

Three short sentences with zero filler; the action and its scope constraint are front-loaded before the requirements. Every sentence adds a distinct 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?

An output schema exists, so return values need not be explained, and the safety gating for this mutation is covered. What is missing is any statement about permanence/undo and failure behavior when the feature flag is off, which would round out a delete tool.

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 schema already documents confirm, draft_id, and account_id. The description only restates the confirm=true constraint already present in the schema and adds no format or default details. Baseline 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?

States a specific verb (Delete) and resource (draft), and the clause 'Only acts on drafts' bounds the scope so an agent can distinguish it from the broad message-deletion siblings like imap_delete_message and imap_bulk_delete. No ambiguity about what object is affected.

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 concrete preconditions for invocation (MAIL_DRAFTS_ENABLED=true and confirm=true), which tells the agent what must be true before calling. It does not, however, contrast itself with siblings such as draft_update or draft_send or state when-not-to-use.

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 burden and does disclose behavior beyond the schema: result ordering (newest first), a returned identifier, and a config prerequisite (MAIL_DRAFTS_ENABLED=true). It does not state pagination/truncation behavior or read-only safety explicitly, but the gaps are modest for a list 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?

Two compact sentences, with the core purpose front-loaded and the prerequisite appended. 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?

For a simple read-only list tool with an output schema present, the description covers purpose, ordering, and the feature-flag requirement, which is sufficient for an agent to call it correctly. Only minor operational details (pagination, empty-state 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 description coverage is 100% — both limit (1..50, default 20) and account_id (defaults to "default") are fully documented in the schema. The description adds nothing about these 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?

States a specific verb (List) and resource (the account's drafts), plus the ordering (newest first) and a returned field (draft_id). It is clearly distinguishable from the write-oriented siblings draft_create/draft_update/draft_delete/draft_send, though it does not name any 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?

Provides a precondition (MAIL_DRAFTS_ENABLED=true), which is useful gating context, but gives no explicit when-to-use guidance or when-not/alternative routing (e.g., versus a search or status tool). Usage is only implied by the verb.

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, and it discloses the key behavioral facts: the operation mutates state and destroys the draft ('remove it from Drafts'), and it requires MAIL_DRAFTS_ENABLED=true and MAIL_SMTP_WRITE_ENABLED=true. It does not state irreversibility or failure behavior, but the side effect and config gating are the most important facts an agent needs.

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, zero filler, with the primary action stated first and the prerequisites following. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description covers the action, its destructive side effect, and the required feature flags. What remains thin is routing relative to the many send-capable siblings, but for this simple two-parameter tool the definition is close to 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?

Schema description coverage is 100% for both parameters, so the schema already documents draft_id and account_id. The description adds no syntax, format, or default semantics beyond what the schema provides, which is the baseline 3 case.

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 ('Send an existing draft') plus the resulting side effect ('remove it from Drafts'), so it is clearly distinct from draft_create, draft_update, and draft_delete. It does not explicitly name or contrast with smtp_send_message, which sends a new message, so the sibling differentiation is implied 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 phrase 'existing draft' implies the applicability condition (a draft must already exist), and the two feature-flag prerequisites give real context for when the call will succeed. However, there is no explicit guidance on when to prefer this over smtp_send_message or graph_send_message, and no when-not 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, the description carries the full disclosure burden and does well: it warns that this is a full rebuild, that unlisted attachments are dropped, that a new draft_id is issued, and that the old id stops working. It omits error/permission behavior beyond the env flag (e.g., what happens if the draft no longer exists), 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?

Three tight sentences, with the destructive replacement semantics front-loaded ahead of the side effect (new draft_id) and the prerequisite flag. Nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers mutation semantics, side effects and the enablement gate. Remaining gaps are edge cases such as invalid/expired draft_id handling or account scoping, which are minor for this tool's 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?

Schema description coverage is 100% and includes a nested AttachmentInput with per-field guidance, so the structured data already documents all 12 parameters. The description only names the field groups being replaced, adding no format or constraint detail beyond the schema — baseline 3.

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 (Replace) and resource (a draft's recipients, subject, body and attachments), and the parenthetical 'full replacement' immediately separates it from an additive/patch-style sibling like draft_create or draft_delete. An agent can select it without opening another 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?

Conveys the usage mode (full replacement, not merge) but never states when to reach for this tool over draft_create, draft_send or draft_delete. The prerequisite flag is a gate, not a routing rule, so usage is implied rather than guided.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Get full email content' transparently indicates a read operation with no side effects, and 'full' clarifies the scope beyond the schema's 'get message details'. However, it does not address auth requirements, error behavior, or EWS-specific constraints, so it is only partially 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?

A single sentence of 13 words with the verb and resource front-loaded. Every word earns its place, and there is no redundant filler or restatement of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 params, no nested objects), and the output schema plus full parameter schemas cover invocation details. The only gap is the missing explicit link to ews_search_messages as the source of item IDs, but the prerequisite is implied by 'using an EWS item ID'.

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 adds little beyond reinforcing that item_id is the EWS identifier. It does not mention account_id, so it adds no significant semantic value over 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 specific verb ('Get'), resource ('full email content'), and method ('via Exchange Web Services'), plus the required input ('EWS item ID'). This clearly distinguishes it from siblings like imap_get_message or graph_send_message by protocol and operation.

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 context is implied: 'via Exchange Web Services' tells the agent this is the EWS option, and 'using an EWS item ID' implies the caller must already have an item ID (likely from ews_search_messages). However, no alternatives are named and no explicit when-to-use/when-not-to-use guidance 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?

With no annotations, the description must carry behavioral disclosure. It conveys a read-style search operation and lists supported folders, but it does not mention whether messages are marked read, permission requirements, pagination behavior, or search syntax. This is adequate but has clear gaps.

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 deliver the protocol, preferred account type, and folder scope with no filler. The key action and context are front-loaded before the supporting folder list.

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 and schema surprisingly expose no search query or criteria parameter, yet the tool is named 'search_messages'. An agent has no way to know what text/filters to provide or how the search is performed, which is a critical gap for invoking it correctly. The output schema helps with return shape but not with the missing search input.

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 schema already documents all four parameters (limit, folder, offset, account_id). The description adds only the folder enumeration, which mostly duplicates the folder parameter's allowed values. No additional parameter-level meaning is needed.

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 action ('Search emails') over a named protocol ('Exchange Web Services') and delimits the resource scope to well-known mail folders. This distinguishes it from IMAP-based search siblings like imap_search_messages and from ews_get_message, which focuses on retrieving a specific message.

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?

'Preferred for Microsoft accounts' provides a clear context for when this EWS tool should be selected, especially alongside IMAP and Graph siblings. It does not name an explicit alternative or exclusion condition, so it stops 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?

No annotations are provided, so the description must disclose behavioral traits on its own. It only states that it sends email via EWS, but does not mention prerequisites (e.g., account setup), potential side effects (e.g., sent vs drafts), error handling, rate limits, or authentication requirements. The absence of such details leaves a significant gap for a mutation 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 a single, efficient sentence with no filler. The purpose is front-loaded with the verb and resource, and the differentiator (blocked SMTP/Graph) is included without excess.

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 9 parameters, all described in the schema, and an output schema present, the description is minimal but does not introduce critical missing context. It fails to mention any constraints like attachment support, account requirements, or explicit alternatives, but the schema covers parameters. The description is adequate but not thorough for a tool with many 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?

Schema coverage is 100% since every parameter has a description in the input schema. The description adds no parameter-specific information beyond the schema, so it meets the baseline for well-documented schemas.

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 verb 'Send' and the resource 'email via Exchange Web Services'. It also distinguishes from SMTP and Graph API by noting it works on tenants that block those, effectively separating it from sibling send tools like graph_send_message and smtp_send_message.

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 when to use: when SMTP and Graph API are blocked. It provides a condition but does not explicitly name alternatives or say 'use this instead of X when Y'. The implication is clear enough for an agent to infer, but it could be more 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, the description carries the full burden of behavioral disclosure. 'Get detailed setup instructions' clearly signals a read-only, side-effect-free retrieval operation. It could add detail about whether instructions are static or fetched externally, but for a zero-parameter guide lookup the behavior is adequately 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 a single 12-word sentence that front-loads the verb and resource, then adds illustrative provider names. Every word contributes to conveying meaning; there is no filler 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?

For a parameterless tool with an output schema present, the description fully covers the purpose and scope. The output schema handles return-value details, so nothing an agent needs to invoke the tool correctly 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?

There are zero parameters, so the description carries no parameter-documentation burden. Per the baseline for an empty parameter list, 4 is appropriate; the description correctly implies that no provider selection is needed.

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-resource pair ('Get detailed setup instructions for email providers') with concrete examples (Microsoft OAuth2, Gmail, Zoho). It is the only sibling tool whose purpose is obtaining setup guidance, so an agent can immediately distinguish it from the message-operation and account-verification 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 makes the use context clear: use this tool when you need setup instructions for email providers. It does not explicitly state when not to use it or name alternatives, but there are no competing siblings for this purpose, so the context is unambiguous.

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 much of the behavioral burden. The top-level description only says 'via Microsoft Graph API', while the schema's own description adds that it uses POST /me/sendMail and requires OAuth2 with Mail.Send. The behavior is available to the agent through the schema, but the description itself adds no extra behavioral insight.

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 imperative sentence with a tightly scoped parenthetical manages to convey both the action and the prime usage condition 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?

The combination of the compact description and the rich schema (100% param coverage, output schema, nested attachment definition) gives the agent everything needed to invoke it. The only thing absent from the description/schema is an explicit comparison to smtp_send_message, but the attention-grabbing definition is 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 does not mention any of the 12 parameters, but the schema provides 100% description coverage for every field, so the baseline of 3 applies. The schema fully describes recipients, subject, bodies, attachments, and threading fields.

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 target (send email via Microsoft Graph API) and immediately gives the critical use-case context (required when SMTP is blocked for personal hotmail/outlook.com accounts). This clearly separates it from sibling SMTP/EWS/IMAP senders.

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

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

The parenthetical gives a clear condition for choosing this tool: personal hotmail/outlook.com accounts where SMTP is blocked. It does not explicitly name the preferred alternative (e.g., smtp_send_message) or describe when NOT to use it, but the context 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the basic action and does not mention side effects, authentication/account requirements, whether the mailbox must exist, message flags, or error conditions. The 'raw RFC822' wording hints at no transformation, but that is minimal.

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

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

The description is a single front-loaded sentence with no filler or redundant phrasing. Every word contributes to the core operation, making it easy to parse quickly.

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 append operation with fully documented parameters and an output schema available, the description is minimally viable. However, it omits operational context such as precondition of mailbox existence, account selection behavior, and whether the append modifies or preserves the raw message, so an agent may still make incorrect assumptions.

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 parameters are already documented with clear meaning (mailbox name, raw RFC822 content as UTF-8, account identifier with default). The description adds no parameter semantics 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 states a clear verb-resource pair: append a raw message to a mailbox. It is distinct from sibling operations like imap_move_message, imap_copy_message, and the send_message tools, since 'append' uniquely means inserting a message into an IMAP mailbox.

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 no guidance on when to use this tool versus alternatives such as smtp_send_message or graph_send_message, nor does it mention whether the mailbox must already exist via imap_create_mailbox. The only implied usage is the action itself, with no explicit 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?

No annotations are present, so the description must carry the behavioral burden, and it only says 'Delete'. It does not state that deletion is irreversible, that `confirm` must be true, or what happens to a batch if some IDs are invalid. The 'up to 500' limit is helpful but insufficient for a destructive 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 a single compact sentence that front-loads the core action and limit. It is appropriately terse, though the lack of any usage context slightly limits its informational payoff.

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?

This is a destructive bulk operation with no annotations, multiple closely related sibling tools, a confirmation parameter, and a batch limit; the description alone does not provide enough context for an agent to safely select and invoke it. It omits when to use it, its destructive implications, and how confirmation is handled, despite having an output schema to cover return values.

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 property descriptions already explain the required confirm flag and message ID constraint. The tool description adds little beyond the word 'bulk', so it meets the baseline but does not enrich the parameter semantics.

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 concrete action ('Delete') and a resource dimension ('up to 500 messages in one operation'), which conveys the bulk nature of the tool. However, it does not explicitly distinguish this from imap_search_and_delete, which can also delete multiple messages, or clarify that target messages are supplied by message IDs.

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 no guidance about when to use imap_bulk_delete instead of imap_delete_message, imap_search_and_delete, or imap_bulk_move. The schema notes that message IDs must be from the same mailbox, but no explicit when-to-use or alternative-selection cues are given.

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

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

No annotations are provided, so the description carries full responsibility for behavior disclosure. It exposes the 500-message cap but does not state that moving removes messages from the source mailbox, what happens on partial failure, or whether the operation is atomic. With no annotations, this is a meaningful gap.

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

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

The description is a single, efficient sentence that begins with the action and resource, includes the key limit, and has no filler. It is well-structured and high-value for its length.

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 schema and output schema are rich, covering parameter meanings and return structure, so the description does not need to restate those. However, with no annotations, the description is still too thin: it does not help an agent decide when to use this over imap_move_message or imap_search_and_move, and it does not communicate source-removal consequences or error-handling expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all three parameters and all constraints (including that message_ids must come from the same mailbox), so schema coverage is 100% and the baseline is 3. The description's only extra contribution is the batch limit, which is a useful clarification but not beyond what provenance the schema provides.

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?

Description says 'Move up to 500 messages to a mailbox in one operation', which is a specific verb (move), resource (messages), and scope (up to 500, one mailbox). This clearly distinguishes it from siblings like imap_move_message (single message) and imap_search_and_move (search-then-move).

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 does not state when or when not to use this tool. It is not compared with imap_move_message, imap_search_and_move, or other alternatives, and there is no prerequisite or context direction. The only implied guidance is the bulk limit, which is not enough to help an agent pick between 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?

With no annotations, the description carries the full burden of behavioral transparency. It mentions the limit of 500 messages, which is good, but it does not disclose that the operation is a write/mutation, whether it is reversible, what happens on partial failures, or whether it requires authentication. The description gives a minimal hint of scope but lacks deeper behavioral 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 a single sentence, efficient and to the point. It front-loads the key action and limit. However, it is under-specified in other dimensions, relying heavily on the schema, which is acceptable for conciseness. It earns a 4 because it is appropriately sized for 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?

Given the tool has 4 parameters and no annotations, the description is incomplete. It does not mention any error handling, partial updates, or the need for at least one of add_flags or remove_flags. The output schema exists but the description does not explain what the response contains. For a bulk operation, it should provide more context about batched behavior and side effects.

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 baseline is 3, but the description itself does not add any meaning beyond the schema. The schema already explains that 'message_ids' must be from the same mailbox and 'add_flags' and 'remove_flags' are optional. The description does not clarify the relationship between add_flags and remove_flags (e.g., whether at least one must be set) or provide examples. It adds no value beyond the schema, so I dock to 2.

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 says 'Update flags on up to 500 messages in one operation', which identifies the action (update flags) and the resource (messages), but it does not distinguish this tool from its sibling 'imap_update_message_flags'. Given the sibling exists, the description should specify the bulk nature as a differentiator; it does state 'up to 500 messages' but lacks explicit contrast. This is clear but not fully differentiating.

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 no guidance on when to use this tool versus alternatives. Siblings like 'imap_update_message_flags' suggest a single-message alternative, but the description does not mention it or any conditions for choosing one over the other. There is no mention of limitations like 'message_ids must be from same mailbox' (that is in schema), and no 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?

Annotations are absent, so the description carries the full behavioral burden, and it is only a single clause. It does not state whether the source message remains intact (the key difference from imap_move_message), whether the destination mailbox must already exist, whether duplicates are allowed, or what error states exist. The cross-account capability appears in the schema description, not the tool description; the tool description itself discloses almost no behavior beyond the verb 'copy'.

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?

At six words, the description is maximally front-loaded and has no filler; every word earns a place. The brevity reads as telegraphic rather than distilled ('to mailbox' lacks an article), but there is no redundancy or burying of the key action.

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 moderately complex operation that supports cross-account copies and has no annotations, the one-sentence description is too thin. An agent still has to guess what happens when the destination exists, whether the source is preserved, and how conflicts are handled; although the output schema covers return shape, the behavioral envelope is largely missing beyond the schema's parameter notes.

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 each of the 4 parameters (account_id, message_id, destination_mailbox, destination_account_id) has a type, description, and default/nullability. The tool description adds nothing about parameters, but with the schema carrying full weight, the baseline of 3 applies. Cross-account semantics are effectively explained in the schema 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?

The description states the specific verb (copy) plus resource (message) and destination (mailbox), so the core purpose is unambiguous. It distinguishes from siblings mainly through the semantics of 'copy' as opposed to imap_move_message or imap_delete_message, but the differentiation is implicit rather than 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?

The description gives no guidance on when to use this tool over alternatives like imap_move_message, imap_append_message, or ews tools, and no exclusions or prerequisites. The schema description mentions 'same-account or cross-account copies,' which is scope context but not routing guidance. An agent must infer when copy rather than move or append is appropriate.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It discloses the core mutation but says nothing about behavior when the mailbox already exists, whether nested folders are auto-created, or what side effects occur on the selected account.

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

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

The description is a single sentence with no filler and the action is front-loaded. It is efficient, but it sacrifices potentially useful behavioral context for brevity.

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 is simple, has only two parameters, full schema coverage, and an output schema, so a terse description is viable. Still, it lacks guidance on duplicate handling, nested folder behavior, or account selection implications, making it minimally complete rather than fully helpful.

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 both account_id and mailbox_name already have meaningful descriptions, including an example of hierarchical mailbox naming. The tool description adds no extra parameter semantics, so the baseline 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 clearly states the operation (create) and the resource (mailbox/folder), so an agent can tell it is the creation counterpart to imap_delete_mailbox and imap_rename_mailbox. However, it does not explicitly differentiate from siblings beyond the word 'new', so it is clear but minimally 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?

No usage context is provided beyond the self-evident purpose of creation. There is no mention of prerequisites, when to prefer this over other mailbox operations, or conditions such as avoiding duplicate mailbox names.

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 surfaces only that the operation deletes a mailbox/folder, but there are no annotations for readOnly or destructive behaviorconstant, and it does not disclose that deletion is irreversible or what happens to contained messages. Behavioral bar is higher in the absence of annotations.

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

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

The description is a single concise sentence with zero filler; the action and target are front-loaded.

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 destructive tool with no safety annotations, the description is too thin. It omits irreversibility, impact on contained messages, and any distinction from near-siblings like imap_bulk_delete or imap_search_and_delete. The output schema partially compensates, but key behavioral 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?

No parameter detail is given beyond the target object. The schema presumably defines mailbox/folder and account parameters, so this is acceptable minimalism, but the description does not clarify essential usage semantics like which identifier is required.

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 deleting a mailbox/folder)Skip, which is specific enough to distinguish from message-level tools like imap_delete_message. It does not explicitly contrast with sibling mailbox operations, but the verb and target resource are 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?

No guidance is given on when to use this tool versus alternatives such as imap_rename_mailbox, imap_bulk_delete, or imap_search_and_delete. The description is limited to what the tool does, not when it is appropriate.

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 states the action (delete) and the confirm requirement, but does not disclose whether deletion is permanent, whether it moves to trash, whether it requires specific permissions, or what the output/return value is. The confirm parameter is mentioned in the schema, so the description adds little beyond 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 description is extremely short ('Delete a message'), which is concise but under-specified. It front-loads the core action but omits important context. The schema description repeats the tool name and confirm requirement, adding some structure but not much value.

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 destructive nature and the presence of many sibling deletion tools, the description is incomplete. It does not explain the deletion semantics (permanent vs trash), the confirm flag's purpose beyond the schema, or how this differs from imap_bulk_delete and imap_search_and_delete. The output schema exists but the description doesn't reference what happens after deletion.

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 schema already documents all three parameters. The description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate because 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?

The description 'Delete a message' states a clear verb and resource, but it does not differentiate from sibling tools like imap_bulk_delete or imap_search_and_delete, which also delete messages. The input schema's description adds a bit more context ('Requires explicit confirm=true') but the tool description itself is minimal.

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

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

No guidance is provided on when to use this tool versus alternatives like imap_bulk_delete or imap_search_and_delete. The schema mentions the confirm requirement, but there is no explicit context about when this tool is appropriate or when a sibling should be chosen.

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 text carries the burden. The schema-filled description explains the non-trivial behavior: it writes decoded bytes to disk and returns a path, keeps large binaries out of the response, and only inlines base64 when explicitly requested via include_base64 with a size ceiling (max_inline_bytes), "off by default to protect the context window." Small gaps remain (overwrite policy, error when the attachment is not found), but the core side effects are 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?

A single seven-word sentence that front-loads the purpose with zero filler; all the detail efficiently lives in the schema. If anything it is almost too terse on its own (it doesn't mention file-side returns), but it does its part alongside the schema and is appropriately sized.

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 and 100% parameter documentation, an agent can invoke this tool: message_id is required, part selection by part_id or filename is described, defaults and environment-behavior are given, and the inline-base64 safety contract is stated. The only real ambiguity is that neither part_id nor filename is explicitly required — an agent could call it with only message_id; a brief 'supply one of part_id/filename' line would make the contract airtight.

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 parameters are already well-documented: part_id takes precedence over filename, filename is case-insensitive, output_dir falls back to environment variables or system temp, max_inline_bytes defaults to 256 KiB. The description itself adds no extra meaning beyond these, which is consistent with the baseline-3 rule for high 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 is a compact, specific claim: 'Download one attachment to disk' — a verb, a resource, and a destination. It distinguishes this tool from siblings like imap_get_message and imap_get_message_raw (which fetch the message, not an attachment) and from ews_get_message, so an agent can pick the right tool from the name/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?

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives in the description. The schema hints at the workflow implied by 'as shown by imap_get_message' (list a message's attachments first), but that is an implicit pointer rather than a stated selection rule, so the agent must infer the 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?

No annotations are present, so the description carries the full burden. It only states 'Get parsed message details', without disclosing whether the operation has side effects (e.g., marking messages as read), what happens on missing messages, or any rate limits/auth requirements. The phrase 'parsed' hints at processing, but most behavioral context is left to the schema.

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

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

The description is a single short sentence with no filler words, so it is concise. However, it is so minimal that it does little more than restate the tool's function; there is no structured context beyond the one phrase.

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 8 parameters, no annotations, and many sibling tools, the one-sentence description is insufficient. The output schema covers return values, but the description does not explain how this tool fits among `imap_get_message_raw`, `imap_get_attachment`, `ews_get_message`, or when the various enrichment flags are 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%, so the baseline is 3. The tool description itself adds no parameter-level meaning; all parameter semantics are already in 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 ('Get') and resource ('parsed message details'), making the core function clear. However, it does not distinguish itself from sibling tools such as `imap_get_message_raw` or `ews_get_message`, so the agent cannot tell exactly what makes this variant unique.

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 mention of when to choose this tool over alternatives like `imap_get_message_raw`, `imap_get_attachment`, or `ews_get_message`. No conditions, exclusions, or routing advice are provided.

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 word 'bounded' and the schema's max_bytes parameter indicate that the returned source may be truncated by a byte limit, which adds some behavioral clarity. However, with no annotations, the description does not disclose side effects, error behavior when max_bytes is exceeded, or authentication/state assumptions.

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

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

The description is a short, front-loaded phrase that communicates the core operation without redundant filler. It could add more context without becoming bloated, but it is concise and clear.

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 getter with a well-described schema PB and output schema, the description covers the basic operation. It omits when to use raw source versus imap_get_message or imap_get_attachment, and does not state that output may be truncated, which is relevant for an agent fetching a bounded raw message. Overall, this is serviceable but missing some decision-relevant context.

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 describes all three parameters, including the required message_id and the max_bytes range/default, so parameter meaning is well covered. The tool description adds only the 'bounded' concept, which maps to max_bytes, but the schema carries most of the semantic weight.

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: 'Get bounded RFC822 source,' which clearly identifies the operation as retrieving raw, size-limited email source. It does not explicitly contrast this with sibling tools like imap_get_message or imap_get_attachment, so its differentiation is implied 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?

There is no guidance on when an agent should choose this tool over the similar siblings imap_get_message or imap_get_attachment. The description states what it does but not the intended use cases or prerequisites (e.g., needing the raw RFC822 source rather than a parsed representation).

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 must carry the behavioral disclosure burden. 'List configured IMAP accounts' implies a read-only operation, but it does not clarify whether this validates connections, requires authentication, or how it differs from a full capabilities view beyond the sibling reference.

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

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

The description is a single concise phrase with a useful sibling pointer. Every word earns its place and the key action is front-loaded.

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 listing tool, the description is mostly complete: it names the resource and the distinction from list_all_accounts. The lack of detail about whether this performs any connectivity checks or what the output shape looks like is a minor gap, but the output schema likely covers the latter.

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 and the schema is trivial. With no inputs to document, the description does not need to add parameter-level detail. Baseline of 4 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 clearly states the tool 'List configured IMAP accounts' with a specific verb and resource. It distinguishes itself from the sibling list_all_accounts by pointing to it as the 'full capabilities' option, which differentiates the two without opening schemas.

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 one routing hint: use list_all_accounts for a full capabilities view. However, it does not explain when to choose imap_list_accounts over imap_verify_account or other listing-related tools, nor does it state any limitations of this view.

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 disclosure. The verb 'list' implies read-only behavior, but the description does not explicitly state side effects, safety, or whether data is modified. It adds no behavioral detail beyond the bare action.

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

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

The description is a single, clear sentence with no superfluous words. It is perfectly sized for a simple list operation, with the action and scope front-loaded.

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 only one optional parameter, an output schema is present, and the operation is a straightforward list. The description adequately conveys the purpose, and the output schema covers return details. It does not, however, explain that the list is scoped to the given account ID, though that is implied.

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 account_id parameter is fully documented in the input schema with a default value of 'default'. The description only says 'for an account' and adds no supplementary meaning to the parameter. Since schema coverage is 100%, a 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 the specific verb 'list' and names the resource 'mailboxes' for an account, making the action unmistakable. It does not explicitly differentiate from sibling tools like imap_list_accounts or imap_mailbox_status, but the resource is clear.

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, no mention of related operations such as listing accounts or checking mailbox status, and no exclusions. The agent receives no contextual direction beyond the description itself.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that the mailbox is not selected, which is a meaningful side-effect guarantee. It also indicates the return focus (message counts) even though the output schema already exists. It does not cover errors or authentication, but for a simple read-only status tool this 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?

A single sentence with no filler. It front-loads the action and resource, then adds the key behavioral differentiator ('without selecting it'). Every word contributes value.

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 two-parameter tool with a complete output schema and a clear, low-risk behavior, the description is fully adequate. It explains what the tool returns, confirms the no-selection behavior, and the schema covers all invocation details.

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 baseline is 3 and the schema already documents both parameters (mailbox and account_id). The description adds no parameter-specific meaning beyond the schema, and that is acceptable because the parameters 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 opens with a specific verb and resource ('Get mailbox message counts') and narrows the scope to total, unseen, and recent counts. It distinguishes itself from sibling message-fetching and search tools (e.g., imap_get_message, imap_search_messages) by stating it does not select the mailbox.

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

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

The phrase 'without selecting it' gives clear context that this is a lightweight, side-effect-free status check, which tells the agent when to use it instead of operations that require mailbox selection. It does not explicitly name alternatives or exclusions, but the context is clear enough for correct 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?

With no annotations provided, the description carries the full burden for disclosing side effects, yet it only says 'Move a message to mailbox.' It does not state that the message is removed from the source mailbox, whether the destination must already exist, or any error/permission consequences. The same-account limitation is additionally hidden in the schema description.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately compact, though it sacrifices useful behavioral context for brevity.

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 mutating operation with no annotations, the description is too thin. It omits the same-account limitation and the destructive effect on the source mailbox, leaving the agent to discover these from the schema description or infer them from the tool name. The output schema covers return shape, so that part is not a gap.

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 all three parameters already have meaningful descriptions, so the schema carries the parameter-level semantic weight. The tool description adds no additional parameter detail beyond this.

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 operation: moving a message to a mailbox, with a specific verb and resource. It does not explicitly distinguish itself from siblings like imap_bulk_move or imap_copy_message, so it stops short of full differentiation.

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 no guidance on when to use this tool over imap_bulk_move, imap_search_and_move, or imap_copy_message. The same-account constraint appears only in the schema description, not in the tool description, so an agent must infer usage from the name alone.

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 burden of behavioral disclosure. It only repeats the mutation implied by the name and does not mention effects on messages, permission requirements, reversibility, or error conditions.

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

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

The description is a single, short sentence with no filler and the core action is front-loaded. It is efficient, though it sacrifices potentially useful context for brevity.

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 rename operation, the description plus the complete schema is roughly adequate. However, with no annotations and no usage guidance, the agent is left to assume behavioral details such as whether the mailbox must be empty or whether the operation is reversible.

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 fully documents all three parameters (from_name, to_name, account_id), giving 100% coverage. The description adds no parameter-level meaning, but the schema already provides the necessary context, so the baseline score 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 ('Rename') and a clear resource ('mailbox/folder'), which distinguishes it from sibling move/create/delete tools. It is slightly terse but not tautological or misleading.

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 on when to use this tool versus imap_create_mailbox or imap_delete_mailbox, nor any mention of prerequisites or side effects. The agent must infer usage from the tool name alone.

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, and it does disclose two behavioral facts: results are returned newest first and are labelled with their originating mailbox. It says nothing about cost/latency of fanning out across all mailboxes, permission requirements, or pagination limits.

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

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

A single sentence that front-loads the scope-defining clause ('Search every mailbox of an account in one call') before the example and output notes. Every clause adds information; nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter tool with full schema coverage and an output schema, the description covers the essentials: scope, the cross-mailbox conversation use case, and result ordering. It omits the 'at least one criterion required' constraint, though the schema description states it.

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 all 15 parameters are already documented in the schema, including limit ordering, date formats, and thread_message_id semantics. The description's mention of thread_message_id duplicates schema content rather than adding new parameter meaning, so the 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?

States a specific verb and resource with explicit cross-mailbox scope ('Search every mailbox of an account in one call'), which inherently separates it from the single-mailbox imap_search_messages sibling. It stops short of naming that sibling directly, so an agent still has to infer the comparison rather than being routed to it.

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?

'e.g. a whole conversation via thread_message_id' supplies one concrete scenario, which is genuine usage context. However there is no explicit when-not-to-use guidance and no named alternative (e.g. imap_search_messages for a single folder), leaving the choice between the two search tools to inference.

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 present, so the description must carry the behavioral burden. It correctly signals destructive intent ('delete') and the 500-message cap, but does not state that deletion is permanent or how confirm=true gates execution. For a destructive combined operation this is a significant gap.

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

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

One short sentence front-loads the purpose and the cap; no filler 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?

The tool is complex (12 params, required confirmation, destructive + search behavior), yet the description is a single phrase. It omits irreversible delete semantics, the confirm gate, how matching works across criteria, and what the response/outcome looks 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?

The input schema already documents each parameter well, so the description does not need to duplicate them. It adds nothing about how filters combine or matching semantics, but with ~90% schema coverage the baseline 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?

Clearly states the operation: search messages and delete matches in one combined action, including the 500-message cap. It distinguishes this from pure search or pure delete tools, though it does not explicitly name a sibling tool.

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

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

The phrase 'in one operation' hints at the use case (avoiding separate search-then-delete calls), but there is no guidance on when to choose this vs. search_messages, mailbox requirements, or safety steps like requiring confirm=true. No conditions or exclusions are given.

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

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

No annotations are provided, so the description must convey behavioral details. It discloses the operation (search and move), the limit of 500 messages per call, and that it returns up to 500 messages. It does not mention whether moved messages are flagged as read or if the operation is reversible, but the provided details are reasonable for the tool's 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 very concise, just two sentences in the main description. The schema description expands with details but the tool's description is front-loaded with the primary purpose and key limitation. Every sentence is valuable.

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 (12 parameters, output schema present, and schema covering all parameters), the description is sufficient. It does not explain the output schema contents, but that is likely documented in the output schema itself. It adequately explains the combined operation and the limit, which is the most critical constraint.

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 parameters are fully documented in the schema. The description adds context by mentioning the limit (500) and the single call nature, but does not add further meaning beyond the schema. Therefore baseline 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 clearly states what the tool does: 'Search messages and move matches to a mailbox in one operation'. The verb and resource are specific, and the schema description adds context about combining search and move. It is distinguishable from siblings like imap_search_messages and imap_bulk_move, though it doesn't explicitly name the 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?

It implies usage context by stating it combines search + bulk move to avoid round-trip overhead, which suggests it is used when needing to move search results in bulk. However, it does not explicitly state when to prefer this over separate imap_search_messages + imap_bulk_move calls, so guidance is clear but not comprehensive.

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 mentions cursor pagination, which is genuinely useful context, but says nothing about read-only semantics, result limits, how cursors are threaded across calls, or typical latency/cost.

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

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

A single front-loaded sentence with zero wasted words. It is arguably too terse for a 15-parameter search tool, but nothing in it is 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?

An output schema exists, so return format need not be explained, and the schema fully documents parameters. Still, for a multi-criteria search tool with four sibling search variants, the description omits filtering capability and cursor flow detail that would help an agent 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 all 15 parameters (from/to/subject/query/date filters, limit, cursor, snippet options) are already documented in the schema. The description adds no parameter meaning beyond that, which lands at the baseline 3.

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 clear verb+resource ('Search messages'), which an agent can understand immediately. However, it does nothing to distinguish itself from siblings like ews_search_messages, imap_search_all_mailboxes, imap_search_and_delete, and imap_search_and_move, so scope boundaries are left to inference.

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 no when-to-use guidance, no prerequisites, and no mention of when a sibling search tool is preferable. It only notes the pagination style, which is a property of the tool rather than usage direction.

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 must disclose behavioral details, but it only says flags can be added or removed. It does not state whether existing unlisted flags remain unchanged, exactly when both add and remove are allowed together, or what errors or side effects may occur.

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

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

The description is a single front-loaded sentence with no filler, making it appropriately concise. It is slightly too terse to be fully self-sufficient, but it structurally keeps the essential operation at the front.

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?

While the input/output schemas cover parameter and return semantics, the description omits the contextual layer: no guidance on single-message versus bulk use, no side-effect disclosure, and no distinction from the highly similar sibling `imap_bulk_update_flags`. Given the number of IMAP siblings, this is a meaningful completeness gap.

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 parameters already document `add_flags`, `remove_flags`, `message_id`, and `account_id`. The description adds no parameter-level detail beyond restating the add/remove operation, so the baseline score 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 clearly states the operation as adding or removing IMAP flags, so the action and resource are identifiable. However, it does not distinguish single-message behavior from the sibling `imap_bulk_update_flags`, leaving some differentiation to inference.

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 no when-to-use or when-not-to-use guidance, and names no alternatives. Nothing indicates when to choose this tool over `imap_bulk_update_flags`, `imap_search_and_delete`, or other flag-related siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions verification but does not state whether this performs network calls, requires authentication, or has side effects. It also doesn't describe the output format (despite an output schema existing, the description could clarify typical outcomes like success/failure or connection details). This is inadequate for a tool with potentially significant network 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 a single short sentence, which is concise)Skip. However, it is under-specified; it does not front-load critical details like the requirement of an account_id or the fact that it checks connectivity. Every word is used, but the sentence is too terse to be truly helpful.

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?

Despite having an output schema (which mitigates return-value explanation), the description is incomplete for a tool checking connectivity and capabilities. It should mention that it verifies network access, authentication, and likely returns a report of capabilities. With no annotations and minimal description, an agent lacks essential context to use this tool effectively.

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 description coverage is 100% for the single parameter (account_id), and the description provided in the schema is complete. However, the tool description itself adds no additional meaning beyond the schema. Since coverage is 100%, a baseline 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 'Verify account connectivity and capabilities' states a clear verb and resource, but it is too generic and does not distinguish this tool from its siblings like imap_list_accounts or smtp_verify_account. The purpose is understandable but lacks specificity about what exactly is verified (e.g., IMAP server reachable, authentication works) and does not convey the scope of 'capabilities'.

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 on when to use this tool versus alternatives. With siblings like imap_list_accounts (listing accounts) and smtp_verify_account (similar verification but for SMTP), the description gives no context about choosing between them. An agent would have to infer that this is for IMAP-specific verification, but no exclusions or alternative mentions are provided.

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 and it does solid work: it discloses what the tool returns (accounts plus capabilities) and the implied read-only nature of a listing operation. It could add notes on account source or result structure, but the output schema covers much of the remaining detail.

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 primary action and resource are front-loaded, and the usage guidance is delivered in a short second sentence.

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 parameterless listing tool with an output schema, the description is complete: it names the resource, the returned capability dimensions, and the decision-support purpose. Nothing essential 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 tool has zero parameters and 100% schema description coverage, so there is nothing for the description to clarify. The baseline of 4 applies, and the description adds no parameter-related content, which is appropriate here.

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 ('List'), a clear resource ('all configured email accounts'), and the key differentiator: it reports per-account capabilities for IMAP, SMTP, Graph API, and EWS. This clearly distinguishes it from sibling tools like imap_list_accounts, which is protocol-scoped.

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 explicitly tells the agent when to use the tool: to know which send/read tools to use per account. It does not explicitly enumerate alternatives or exclusions, but the purpose is specific enough that an agent can select it correctly without confusion.

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 full responsibility for behavioral disclosure. It only says 'Forward an existing message via SMTP' and does not disclose how the original is fetched, how the body is handled, what side effects occur (sending a new email), or any failure modes. Behavioral traits are left to the schema or the agent’s guesses.

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

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

The description is a single, front-loaded sentence with no repetitive or unnecessary words. It efficiently says what the tool does without restating the name verbatim. The one-sentence structure is ideal for clarity and quick scanning.

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 schema is rich (100% coverage, detailed parameter descriptions) and an output schema exists, so return values need not be described. However, the description lacks usage context (when to use vs smtp_reply_message, prerequisites, and consequential behavior), which is not fully compensated by the parameter descriptions. It is minimally complete but not genuinely helpful for a human–agent decision.

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 100% parameter coverage with detailed descriptions for each field. The description itself adds no semantic meaning beyond the schema, which is sufficient at the baseline level for a fully-covered schema. Nothing is repeated or expanded in the description text, so no bonus is earned.

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 action ('Forward') and resource ('existing message via SMTP'), which is sufficient to distinguish it from smtp_send_message or smtp_reply_message. However, it does not explicitly call out or differentiate from these siblings, so it lacks the explicit cross-tool comparison that would earn 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?

The description gives no guidance on when to choose this tool over alternatives. It does not mention conditions, prerequisites, or exclude smtp_send_message / smtp_reply_message. Some schema parameters hint at alternatives, but the description text itself offers no usage direction, which is a clear gap given the sibling wave.

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 must disclose behavioral traits. It explains that the tool fetches the original message via IMAP to construct proper reply headers (In-Reply-To, References, Re: Subject), which is a meaningful behavioral detail beyond a simple 'sends a reply.' However, it does not cover error cases, side effects of sending, or whether the operation is safe or reversible. Given the disclosure of the threading implementation, this is above the baseline of 3 but not a full 5 because it omits potential pitfalls (e.g., failure if original not found, sending failure).

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

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

The description is a single, information-dense sentence that leads with the action and immediately adds the key threading detail. There is no fluff or redundancy. Every word contributes to clarifying the tool's purpose and distinguishing it from alternatives.

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 (7 parameters, nested attachment object, output schema present), the description is largely complete: it defines the purpose and key behavior. However, it does not explicitly address sibling selection (e.g., 'use this instead of smtp_send_message when replying') or mention dependencies like IMAP availability. The schema fills parameter details, but the description could better position the tool among the 31 siblings. It is complete enough for a competent agent but leaves some room for clearer guidance.

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 all seven parameters (message_id, body_text, body_html, reply_all, account_id, attachments, include_original_attachments) are already documented with their meanings and defaults. The description adds context about the threading behavior but does not enhance the understanding of any specific parameter. Since the schema carries the weight, a 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 states a specific verb ('Reply') and resource ('an existing message via SMTP'), and adds a concrete differentiator ('fetches original for proper threading'). This clearly distinguishes it from smtp_send_message (new message) and smtp_forward_message (forwarding), 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 implies when to use it (to reply to an existing message) but does not explicitly contrast it with alternatives like smtp_send_message or smtp_forward_message. There is no 'use this instead of...' guidance, nor mention of prerequisites such as the original message being accessible via IMAP. Usage is clear from the name and phrasing, but the description does not actively route the agent away from siblings.

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

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

There are no annotations, so the description carries the full disclosure burden. It only says it sends an email via SMTP and does not mention that delivery is irreversible, that an authenticated SMTP account may be required, or that external network delivery implies potential rate limits/failure modes.

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

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

The description is a single, front-loaded sentence with no filler words. Everything present is directly useful for purpose, and it does not restate the schema or over-explain.

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 this complex (11 parameters, no annotations), the description is minimal and provides little beyond the basic purpose. The schema and output schema fill in almost everything about parameters and return values; the main remaining gap is the broader usage context and side-effect disclosure, which is already reflected in the Usage and Transparency scores.

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 full coverage of parameter descriptions, so the baseline of 3 applies. The description adds no parameter-specific meaning itself, but the schema descriptions already explain usage, required fields, limits, and attachments, so the agent is not left without parameter guidance.

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 ('send a new email via SMTP'), and the words 'new' and 'SMTP' help distinguish it from reply/forward and from Graph/EWS sending siblings. It does not name sibling tools, but the phrasing is specific enough for an agent to identify the tool's basic role.

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 the phrase 'send a new email via SMTP' — the agent can infer it is for new outbound messages rather than replies/forwards. However, there is no explicit when-to/when-not-to guidance and no mention of alternative sending tools like smtp_reply_message, smtp_forward_message, or Graph/EWS senders.

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 word 'test' implies a read-only, non-mutating operation, but no annotations are present and the description does not explicitly state that no message is sent or that only connectivity/auth credentials are checked. It gives a reasonable behavioral hint without fully owning the transparency burden.

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, with no filler words. It is appropriately concise for a simple tool, though it could have included a little more operational context without becoming bloated.

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 one optional parameter and an available output schema, the description is largely adequate. The main missing context is usage guidance and explicit side-effect clarity, which would make it 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?

There is only one optional parameter, account_id, and the schema fully describes it, including its default value. The description adds no extra meaning beyond the schema, so the baseline 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 concrete verb ('Test') and names the specific resource ('SMTP account') and the exact concern ('connectivity and authentication'). It clearly separates this from sending/forwarding/reply tools and from the equivalent IMAP verification tool.

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: verify an SMTP account's reachability and credentials. However, it does not explicitly mention alternatives such as imap_verify_account, prerequisites like prior setup/configuration, or when not to use it.

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