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

Annotations already carry readOnly/openWorld/idempotent hints, so the description's job is lighter. It adds useful privacy context by stating it does not expose passwords or query an external address-book API, and it clarifies the data source (recent mail headers). No contradiction with 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?

Two sentences, front-loaded with the core action and resource, followed by a meaningful privacy qualifier. No redundant or filler language.

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 read-only search with all parameters optional and sensible defaults, the description is usable as-is. However, with no output schema and undocumented query/limit/accountId semantics, an agent still lacks detail about return shape and parameter interaction, so it is only minimally complete.

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

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

The schema has 0% description coverage, so the description must compensate. It only implies the accountScope meaning ('one account or across all accounts'); it does not clarify query matching behavior, limit bounds, or how accountId selects an account. An agent has to rely on name/defaults/schema constraints.

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

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

The description names a specific verb ('search') and resource ('correspondents collected from recent mail headers'), and clarifies the scope ('one account or across all accounts'). It distinguishes this from generic search/mail_search by focusing on contacts from mail headers and explicitly ruling out an external address-book API.

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

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

It clearly states the tool's use case — searching correspondents in one or all accounts — which helps an agent choose it over message-search siblings. It does not explicitly mention alternatives or when not to use it, but the 'correspondents from recent mail headers' scoping makes the boundary reasonably clear.

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

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

Beyond the annotations, the description adds valuable behavioral details: it returns sanitized plain text, includes safe metadata and attachment summaries, and does not mark the email as read. These details supplement the readOnly and idempotent hints and help the agent understand side effects and output characteristics.

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

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

The description is two sentences with no wasted words. It front-loads the usage context ('Use this after search'), states the core action, and adds the most important behavioral caveat about not marking the email as read.

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 one-parameter read tool with strong annotations, the description is largely complete: it explains the output format, the lack of side effects, and the intended workflow. The main gap is the under-explained 'id' parameter, but the overall context is sufficient for a straightforward fetch operation.

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

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

The schema provides no description for the 'id' parameter, and schema description coverage is 0%. The description says 'read one email' but does not clarify that the id should be an email id from a prior search or how to obtain a valid id. Since the description must compensate for the low schema coverage but does not, the parameter semantics are under-specified.

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 ('read') and resource ('one email'), and specifies the output as sanitized plain text with safe metadata and attachment summaries. It also explicitly clarifies that reading does not mark the email as read, which distinguishes this tool's behavior from other email-reading 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 explicitly says 'Use this after search,' providing clear contextual guidance for when the tool should be invoked. It does not mention alternatives or exclusions, but the intended workflow is clear enough for an agent to select this tool appropriately among its 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a meaningful behavioral guarantee: credentials are never returned. This is useful context beyond the 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 two concise sentences with no filler. The primary use case is front-loaded, and the credential privacy note is a valuable, compact addition.

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, read-only list tool, the description covers when to use it and the key behavioral constraint. It does not enumerate return fields, but the lack of an output schema and the simple nature of the operation make this acceptable.

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 schema description coverage is 100%, so there is no parameter documentation burden. The description's mention of account selection and capabilities helps clarify the tool's purpose without needing parameter details.

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

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

The description clearly states the tool lists configured mail accounts and is used for selecting an account or checking account capabilities. It distinguishes itself from sibling tools like list_mailboxes by focusing on accounts rather than mailboxes or messages.

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

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

The description explicitly says when to use the tool: when selecting a configured mail account or confirming which accounts support sending and mailbox changes. It does not mention alternatives or exclusions, but the use cases are specific enough to guide an agent.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds context about when to use it but does not disclose additional behavioral details such as what the response contains (e.g., mailbox names and IDs) or any performance characteristics. Thus it adds only modest value beyond 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 one concise sentence that directly states the purpose and usage conditions without unnecessary words. It is well-structured and front-loaded with the key trigger conditions.

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 simplicity of the tool (one parameter, no output schema), the description is mostly sufficient. It indicates the intended use and context, though it omits explicit mention of the return value (a list of mailboxes). However, this is largely obvious from the title, so the description is nearly complete.

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

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

Schema coverage for the single parameter accountId is 0% and the description does not mention it. Since schema coverage is low, the description should compensate by explaining the parameter, but it fails to do so. The parameter name is self-explanatory, but the description provides no explicit 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 title 'List mailboxes' provides a clear verb and resource, and the description specifies when to use it (needing a folder other than Inbox or an opaque destination mailbox ID for move/copy operations). This distinguishes it from sibling tools like mail_move and mail_copy.

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 states the conditions for use: when a task needs a folder other than Inbox or needs an opaque destination mailbox ID for move and copy operations. This gives clear guidance on when to invoke the tool.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds genuinely useful behavioral details beyond those annotations: text is returned as UTF-8, binary data as base64, and content should be treated as untrusted. It does not cover error behavior or truncation, but the safety profile is well established.

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

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

Three concise sentences with front-loaded purpose, followed by encoding and security guidance. Every sentence adds value and there is no redundant or filler content.

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 relatively simple and the annotations cover its read-only nature, while the schema covers parameter constraints. However, with no output schema, the description does not fully specify the response shape, and the behavior of maxBytes (e.g., truncation vs. failure) remains unclear. These are notable but not fatal gaps.

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 has no property descriptions, so the description needs to compensate. It explains attachmentIndex somewhat ('zero-based index shown by mail_get'), but messageId is not described and maxBytes—including its default, limit, and effect—is left entirely implicit. This is a meaningful gap for correct invocation.

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 identifies a precise action ('read one attachment') and a specific resource ('attachment'), and it clarifies that the attachment is selected by zero-based index as shown by mail_get. This clearly differentiates it from the broader mail retrieval tools like mail_get and fetch.

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 a clear usage context: use this after mail_get to read a specific attachment by index. It does not explicitly list when not to use it or name alternative tools, but the workflow reference to mail_get provides enough situational 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?

The annotations indicate readOnly=false, idempotent=false, and destructive=false, which are informative. The description goes slightly beyond by asserting the operation is a 'copy' (implying non-destructive) and scoping to 'same account,' but it does not mention potential side effects like creating a new message ID or retaining original flags. It lacks explicit behavioral details.

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

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

The description is extremely concise—two short sentences that convey the action, scope, and a key reference for obtaining an ID. There is no redundant wording or extraneous information, 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 tool with no output schema and only two parameters, the description covers the essential context: what it does, where to get the destination ID, and the account scope. It lacks minor details like whether the operation is synchronous or how to handle errors, but these are not critical for a basic copy action. The absence of an output schema reduces the need for return-value explanation.

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 lists two string parameters, messageId and destinationMailboxId, with no descriptions (schema coverage 0%). The description partially compensates by explaining that the destination id comes from list_mailboxes, but it does not clarify what messageId refers to (e.g., the source email ID, format, or how to obtain it). Thus, only half of the parameters receive contextual 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 clearly states the tool's function: 'copy one message to a mailbox in the same account.' The verb 'copy' and object 'message' are specific, and the phrase 'in the same account' adds relevant scope. It also distinguishes this tool from siblings like mail_move and mail_trash by focusing on the copy action.

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

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

The description tells the user to 'Use this to copy one message' and provides the crucial pointer: 'Obtain the opaque destination id from list_mailboxes.' This gives actionable guidance for using the tool correctly. However, it does not explicitly contrast with alternatives (e.g., when to choose copy over move or trash), which would further clarify usage.

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

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

The annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral context: irreversibility ('This cannot be undone'), the confirmation requirement, and the Trash-folder precondition. This goes well beyond the structural annotation hints and fully warns the agent of the destructive nature.

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

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

The description is two sentences with no filler. It front-loads the critical usage restriction and immediately states irreversibility. Every sentence adds substantive 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 destructive operation with no output schema, the description covers the essential preconditions, confirmation requirement, and consequences. Combined with the annotations (destructiveHint=true), nothing important is missing for an agent to call this tool 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 0%, so the description must compensate for parameter documentation. It indirectly explains the 'confirmed' parameter via 'explicit user confirmation', but it does not describe the 'messageId' parameter. However, the meaning of messageId is largely self-evident from the tool name and email context, so the definition provides partial compensation.

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 a specific verb ('delete permanently') and resource (an email message already in the Trash folder). It distinguishes this tool from siblings like mail_trash or mail_move by emphasizing permanent deletion of a message in Trash, making its purpose unambiguous.

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

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

The description gives explicit conditions for use: only after explicit user confirmation and only for messages already in the configured Trash folder. It clearly implies when not to use the tool (e.g., messages outside Trash) but does not explicitly name alternative sibling tools, so it falls just short of a 5.

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

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

The no-send statement adds meaningful behavioral context beyond the bare annotations, and the annotations themselves (readOnly=false, destructive=false) are consistent with draft creation. However, the description does not disclose that drafts are persisted, that repeated calls create new draft instances, or how the draft lifecycle connects to send/discard operations, which would be useful 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?

Two sentences, front-loaded with the action, and no filler. The sending caveat is placed at the end and earns its place because it prevents a likely misuse.

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 12-parameter tool with no output schema and only 2 required parameters, two sentences are insufficient. Important invocation details such as the need for sourceMessageId in reply/forward modes and what the tool returns (e.g., a draft ID) are absent, so an agent would have to infer or experiment to use it correctly in more complex scenarios.

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

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

With 0% schema coverage, the description partially compensates by mapping mode values (new/reply/reply-all/forward) and naming To/CC/BCC, optional HTML, and allowlisted attachments. It omits semantics for sourceMessageId, quoteOriginal, includeOriginalAttachments, bodyText/bodyHtml relationship, and accountId, so it does not fully bridge the schema gap.

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

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

The description states a concrete action ('prepare') on a specific resource (email draft), enumerates supported modes (new/reply/reply-all/forward), and lists key components like To, CC, BCC, and HTML. It also explicitly separates the tool from sending, making it easy to distinguish from mail_draft_send at a glance.

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 opens with an explicit 'Use this to...' directive and includes a clear exclusion: 'It does not send email.' This prevents an agent from selecting it for sending, but it does not name alternatives like mail_draft_send or mail_draft_update, so the routing guidance is clear but incomplete.

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

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

Annotations already declare destructive and idempotent behavior, so the description adds value by specifying that the operation only affects an unsent in-memory draft within this MCP process and has no server-side IMAP deletion effect. That meaningfully clarifies side-effect scope.

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 usage instruction is front-loaded, and the important boundary condition is stated immediately after.

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 simplicity—one required parameter, no output schema, and annotations covering destructive/idempotent behavior—the description is complete enough for an agent to invoke it correctly. The in-memory-only distinction resolves the main potential confusion.

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

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

Schema description coverage is 0%, and the description does not explicitly state that draftId identifies the draft to discard. The parameter name is self-explanatory and the UUID format helps, but the description should have compensated for the missing schema-level documentation.

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 precise verb ('remove'), resource ('unsent in-memory draft'), and scope ('from this MCP process'). The second sentence explicitly distinguishes this from deleting an IMAP Drafts message, which helps separate it from related mail deletion 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 opens with 'Use this to remove...', giving a clear call scenario, and clarifies that this does not delete an IMAP Drafts message, which serves as a useful exclusion. It does not name sibling alternatives explicitly, but the intended 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?

With all annotations false, the description carries the behavioral burden. It usefully discloses that the returned token is short-lived and bound to a specific revision, which is critical for an agent to know. It does not explain side effects or token consumption details, but the core behavior is transparent.

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

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

Three short sentences, front-loaded with the trigger condition, then a precise list of displayed fields, then a vital token-lifetime warning. 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 description covers the trigger, output fields, and token-lifetime property, which is a workable basis for invocation. However, with no output schema and no annotation support, it leaves gaps such as how the returned token should be consumed, what happens if the revision is stale, and whether the preview invalidates prior previews.

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

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

Schema description coverage is 0%, so the description must compensate. It gives some meaning to 'revision' by saying the token is bound to it, but it never defines draftId or explains how to obtain the correct revision value. For two required parameters, this is only minimal compensation.

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

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

The description names a specific verb and resource ('preview email draft'), lists the exact fields the preview shows, and positions it as the step immediately before send approval. This clearly distinguishes it from mail_draft_send, mail_get, and mail_draft_update.

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

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

It explicitly states when to use the tool: immediately before asking the user to approve sending. It does not name alternatives or state when not to use it, but the workflow context is clear enough among the sibling draft 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?

Annotations already indicate this is a non-read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond those annotations: it requires a fresh stable idempotency key and warns that SMTP acceptance is reported separately from final delivery. It does not fully describe failure behavior, but it provides meaningful operational transparency.

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

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

The description is two sentences with no filler. The critical precondition ('only after the user explicitly approves the exact current preview') is front-loaded, followed by required inputs and an important caveat. Every sentence carries essential information.

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

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

For a sensitive send operation with no output schema, the description covers the key prerequisite, required tokens, idempotency, and the SMTP/delivery distinction. It does not describe the response shape or error cases, but the existing guidance is enough for an agent to invoke the tool correctly in the intended approval workflow.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that revision and confirmationToken are tied to the approved preview, that idempotencyKey should be new and stable, and that the confirmed flag corresponds to explicit user approval. DraftId is left implicit as a resource identifier, but overall the description adds substantial meaning beyond the raw 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 clearly states the tool sends an approved email draft, using the specific verb 'send' and resource 'approved email draft.' It also distinguishes this action from other draft operations by requiring explicit user approval of the current preview, so an agent can tell it apart from preview, update, or discard 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 gives a strong precondition: only use after the user explicitly approves the exact current preview. It also implies the necessary confirmation flow by mentioning revision, confirmation token, and idempotency key. However, it does not explicitly name sibling alternatives or state when not to use this tool in favor of another.

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 discloses an important non-obvious behavior: the revision requirement as an optimistic-locking mechanism, preventing stale agent actions from overwriting newer content. It also clarifies that the operation does not send email. This adds meaningful behavioral context beyond the empty annotations, though it does not explain partial-update semantics or the response shape.

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 three short, purposeful sentences. The primary use is stated first, the critical revision constraint is next, and the non-sending behavior is last, with no filler or redundant information.

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

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

Given nine parameters, zero schema descriptions, no output schema, and no helpful annotations, the description is not complete enough for reliable invocation. It covers the core edit action and revision locking, but leaves critical behaviors such as how optional fields affect the draft and how to obtain the current revision 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?

With schema description coverage at 0%, the description carries the full burden for explaining parameters, but it only clarifies revision. It does not explain how to/cc/bcc/subject/bodyText/bodyHtml/attachments should be supplied or whether omitted fields are preserved or cleared during an update.

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 and resource: "edit an existing prepared draft." It clearly distinguishes this from drafting, sending, and discarding by adding "It does not send email," leaving no ambiguity about the tool's 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?

The description gives clear usage context: use when editing an existing prepared draft, and it warns that the current revision is needed to avoid overwrites. It explicitly rules out sending email, though it does not directly name alternative tools like mail_draft_create or mail_draft_send as comparisons.

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 indicate this is a write operation with no read-only, destructive, or idempotent guarantees. The description adds the useful detail that omitted fields are left unchanged, but it does not disclose return values, error behavior, or any side effects beyond flag updates.

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

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

The description is concise, uses two short sentences, and front-loads the purpose before adding the partial-update caveat. Every word contributes meaning.

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 flag-update tool, the description is sufficient to know what the tool does and which fields matter. However, there is no output schema or mention of what the tool returns after a successful update, which leaves some ambiguity for an agent.

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

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

Schema descriptions are absent (0% coverage), but the description maps the boolean flags (read/read, starred/star, answered/answered, draft/draft) and implies messageId identifies the target. This compensates for the missing schema descriptions.

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 states the exact verbs and resources: mark a message read/unread, star/unstar, and update answered/draft flags. It clearly distinguishes this tool from sibling tools focused on moving, deleting, or drafting messages.

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

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

The description explains partial-update semantics ('Only explicitly provided fields change') but gives no explicit guidance on when to prefer this tool over sibling tools such as mail_draft_update or mail_move. No alternatives or conditions are mentioned.

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

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

The description adds an important operational caveat beyond annotations: folder deletion requires confirmed=true and can destroy server-side data. This complements the destructiveHint=true annotation without contradicting it. It could go further by noting effects of unsubscribe or rename, but the key destructive behavior is disclosed.

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

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

Two tightly written sentences with no filler. The main action list is front-loaded, and the destructive deletion caveat is placed at the end where it stands out. Every word 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?

The description is adequate for understanding the tool's purpose and destructive risk, but it leaves gaps for a multi-action tool with five parameters and no output schema. It fails to map action to parameter requirements (e.g., rename vs newFolder) or describe expected return behavior, so an agent may still need to inspect the schema and experiment.

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

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

Schema description coverage is 0%, so the description bears the burden of explaining parameters. It only clarifies confirmed=true for delete. It does not explain that rename likely requires newFolder, how accountId and folder relate to each action, or the role of the confirmed flag outside deletion. Agents must infer most parameter semantics from the schema enum and names.

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

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

The description names a specific resource ('folder') and a clear set of operations: create, rename, delete, subscribe, or unsubscribe. This unambiguously distinguishes it from message-level tools like mail_move, mail_trash, and mail_delete_permanently.

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 'Use this to' gives a clear when-to-use context, and the enumerated folder operations define the tool's scope. It does not explicitly name alternatives or state when not to use it, but the distinction from sibling message-focused tools is strongly implied by the resource being managed.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds useful context beyond this by stating reading does not mark the email as read and that content is sanitized with attachment summaries. No contradictions.

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 with no filler; the workflow hint and key side-effect are front-loaded before the notice about read state.

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 one-parameter read operation, the description covers invocation context, return nature (sanitized text + metadata + attachment summaries), and the notable side-effect absence. Annotations cover safety, and no output schema is needed for this level of 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 coverage is 0%, but the sole id parameter is plausibly an email identifier and the phrase 'after search' implies it comes from search results. The description doesn't explicitly define id's origin or format, so it only partially compensates.

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 action ('read one email'), a resource (an email), and the output format (sanitized plain text with metadata and attachment summaries). This clearly differentiates from sibling search/list/thread 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?

Explicitly instructs to use after search, establishing the workflow context. It doesn't explicitly contrast with siblings such as mail_get_thread or mail_attachment_read, so not 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?

Read-only and idempotent behavior is already covered by annotations, and the description adds valuable behavioral detail: results always include the selected source, bounded results report hasMore/partial, and grouping is never by subject alone.

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 dense sentences with no filler. The main use case is front-loaded, and each clause contributes additional behavioral or scoping information.

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

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

The description covers purpose and key result behavior, but with no output schema and four parameters it leaves parameter semantics and distinction from mail_get/search largely implicit. It is viable but not fully comprehensive.

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

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

Schema description coverage is 0%, so the description must clarify parameters, but it only implies a selected source. id, limit, includeJunk, and includeTrash are not explained, leaving their semantics to inference from names and defaults.

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 and resource: find messages within an email thread using Message-ID, References, and In-Reply-To headers. It also distinguishes behavior from subject-only grouping, which separates it from broader search siblings.

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

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

It gives a clear call to action for thread retrieval and specifies the linking criteria. It does not name alternative tools or explicitly state when not to use it, but the intended context is evident.

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 destructiveHint and readOnlyHint annotations already communicate that this mutates state, and the description adds useful context: it operates on exactly one message and stays within the same account. However, it does not explicitly state that the message is removed from the source mailbox, leaving that important effect implied by 'move' rather than 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 sentences with no filler. The primary action is front-loaded, and the critical lookup prerequisite is placed second. Every sentence adds information.

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

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

For a two-parameter tool with annotations already covering destructive behavior, the description is nearly complete: it defines the operation, limits scope to one message and one account, and tells the agent where to obtain the destination ID. The only notable omission is the source of messageId and return-value behavior, but no output schema exists and those are minor for a move action.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It effectively explains destinationMailboxId as opaque and sourced from list_mailboxes, but it does not explain where messageId comes from or confirm that both IDs are opaque API identifiers. The field names are reasonably self-explanatory, so this is adequate with a clear gap.

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

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

The description states a specific action: 'move one message to a mailbox in the same account.' It clearly identifies the resource (one email message) and scope (same account), and the verb 'move' distinguishes it from related sibling tools like mail_copy and mail_trash.

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

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

It gives a clear usage directive ('Use this to move one message...') and a practical prerequisite ('Obtain the opaque destination id from list_mailboxes'). It does not explicitly call out when not to use it or alternative tools, but the context is clear enough for selection.

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

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

The annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds a behavioral default not in annotations: 'Omitting filters lists recent mail,' and clarifies that searches can span one or all accounts, which is valuable context beyond the schema and 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 two-sentence structure is efficient, front-loading the use condition and enumerating filter categories without filler. The long first sentence is dense but serves to convey the breadth of search capabilities, and the second sentence succinctly captures fallback behavior.

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

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

For a tool with 26 parameters and no output schema, the description gives a strong high-level orientation but lacks per-parameter semantics and response/pagination details. It covers the main use case and default behavior, but an agent would still be uncertain about exact query construction and result handling, so additional description or schema documentation would improve completeness.

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

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

With only 4% schema description coverage, the description must compensate for undocumented parameters. It lists filter categories like subject, body, date, attachment, size, and pagination, but does not map them to exact parameter names (e.g., 'read' vs 'unread', 'starred' vs 'flagged') nor explain enums such as folderScope or accountScope, leaving ambiguity for constructing calls.

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 resource (email) and action (search across one or all accounts) and enumerates the filtering dimensions (folder, sender, recipient, CC, BCC, subject, body, date, etc.), making the tool's purpose unmistakable. However, it does not explicitly distinguish this tool from the sibling 'search' tool, so differentiation relies on the 'Advanced' title and the filter richness.

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 opens with 'Use this when searching one account or all accounts...' which gives a clear condition for invocation. It also notes the default behavior when filters are omitted, but it does not specify when not to use it or point to alternatives like the sibling 'search' tool.

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

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

Annotations already mark the tool as destructive, readOnly=false, and non-idempotent. The description adds important context beyond those flags: the action is a move to Trash, not a permanent deletion, and the target is the account's configured Trash folder. This clarifies the practical effect of the 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?

Two short sentences with no filler. The primary action is front-loaded, and the key non-permanence clarification immediately follows. Every sentence contributes useful information.

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

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

For a single-parameter mutation with annotations and no output schema, the description covers the essential behavior and non-destructive-to-permanence distinction. It could be slightly more complete by naming sibling tools for alternative destinations, but the core invocation context is adequate.

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

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

With schema description coverage at 0%, the description does not explicitly document messageId semantics or format. However, the phrase 'one message' plus the self-explanatory parameter name 'messageId' make the intended parameter role reasonably clear. The schema also provides length constraints.

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 ('move'), a specific resource ('one message'), and a specific destination ('the account's configured Trash folder'). It also explicitly distinguishes the operation from permanent deletion, which separates it from the sibling mail_delete_permanently.

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 clearly indicates when to use the tool: to trash a single message. It also says what the tool does not do ('does not permanently delete'), which helps rule out mail_delete_permanently. However, it does not explicitly name alternative tools like mail_move for moving to a non-Trash folder.

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

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

Annotations already declare readOnly/idempotent/non-destructive; description reinforces as read-only. Adds that results include id, title, and URL, which helps set expectations without contradicting 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?

Two sentences, directly on point, with no redundant words. Efficiently conveys scope, alternative, and output shape.

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?

Specifies global scope (all accounts, non-trash mailboxes), names sibling tool for alternative, and summarizes return fields. Lacks pagination or limit info but sufficient for a simple search tool given no output schema.

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

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

Schema provides query string with min/max but no description; description only says 'simple search' and doesn't explain query syntax or semantics. Parameter name and context imply free-text term, but coverage is 0% and description does not compensate with examples or format details, so score is moderate.

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 it performs a search over email across all configured accounts and non-trash mailboxes. Explicitly distinguishes from mail_search via filter/account scoping, so purpose is unambiguous.

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

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

Explicitly tells agent to use mail_search when filters or account scoping are needed, creating a clear boundary. Also indicates this is the simpler alternative for broad searches, so when-to-use is well specified.

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