Fluxmail

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds genuine domain context by clarifying that "labels" means Gmail labels or Outlook categories, but says nothing about what happens if a label doesn't exist, whether duplicates are ignored, or partial-failure behavior across the ID batch.

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 tight sentence with the action front-loaded and no filler. Nothing is wasted, though the brevity borders on under-specification for a mutation 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?

The output schema, complete parameter coverage, and annotations carry most of the load, so the thin description is workable. What's still missing is any hint about label pre-existence or error handling on a batch mutation, which an agent would want before calling.

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 explains messageIds (up to 100 IDs), accountId (optional with one account), and labels. The description's only addition is the provider-specific meaning of labels, which is a marginal gain; 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 ("Add") and resource ("labels/Outlook categories") applied to messages, which cleanly separates it from remove_labels and list_labels without needing to name them. It is clear but stops short of any explicit sibling 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?

Usage is only implied by the verb: the agent can infer this is the additive counterpart to remove_labels, but there is no statement of when to prefer it, no prerequisite that labels must already exist (no create-label path is mentioned), and no note about batch limits beyond the schema.

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=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the inbox-to-archive effect, but does not describe permissions, reversibility via restore_emails, or what happens to labels/read state.

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?

It is a single front-loaded sentence with no filler. The operation and destination are conveyed immediately.

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 the input schema is fully described, so much of the calling contract is already provided. The description covers the core action but omits sibling differentiation and behavioral details like restorability, leaving a minor 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 coverage is 100%, so accountId and messageIds are fully documented in the schema. The description adds no parameter-level meaning beyond that, which is acceptable at the baseline for high 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?

The description gives a specific verb and resource ('Move messages') plus the destination ('into the archive'), so the operation is clear. It does not explicitly distinguish itself from sibling operations like move_emails or trash_emails, which keeps it from 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 phrase 'out of the inbox into the archive' implies when to use the tool, but there are no explicit conditions, exclusions, or named alternatives such as move_emails or trash_emails. Usage is inferable but not 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?

Annotations already declare readOnly=false, idempotent=true, destructive=false; the description adds the meaningful consequence that the draft survives in the Drafts folder, so content is not lost. That confirms and explains the non-destructive annotation rather than repeating it. It doesn't cover edge behavior such as cancelling an already-sent schedule, but with annotations carrying the safety profile this is solid.

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 identifier, followed by the one behavioral fact that matters. 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?

Output schema exists, so return values need not be described, and the non-loss guarantee is covered. The remaining gap is failure/edge semantics (invalid scheduleId, schedule that has already fired), which would help for an idempotent mutation but is a minor omission for a one-param 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 coverage is 0% and the single parameter is undocumented in the schema, so the description must compensate — and it does by identifying the provenance of scheduleId (generated by send_email with sendAt, or retrievable via list_scheduled_emails). It doesn't state format/constraint details, but the provenance is the semantically important part.

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

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

Specific verb+resource ('Cancel a pending scheduled send') plus the keying parameter (scheduleId), which separates it cleanly from siblings like list_scheduled_emails and send_email. An agent can identify the operation without opening the schema.

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

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

It tells the agent exactly where the scheduleId comes from ('from send_email with sendAt, or list_scheduled_emails'), which implies the workflow context for use. It stops short of naming when NOT to use it — e.g. delete_draft as the alternative when the user wants the content gone entirely.

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 non-destructive, non-idempotent, closed-world behavior, so the bar is lower. The description adds genuine non-schema context: omitted recipients and subject are inherited from the original message when replyToMessageId is set, and replyAll expands to all original recipients. It stops short of stating where the draft lands or that nothing is transmitted.

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 before the conditional reply behavior. Nothing is padded and the conditional is clearly marked by "With replyToMessageId".

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 11 all-optional parameters and an output schema present, the description needn't explain return values, and the reply path — the least obvious usage mode — is well covered. The attachment and send-as paths are undocumented in prose, but the schema carries them at 91% coverage.

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

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

Schema coverage is 91%, so the baseline is 3, and the description earns a bump by explaining the interaction between replyToMessageId, omitted to/subject, and replyAll — cross-parameter semantics the schema documents only per-field. Attachments, from/send-as, and accountId are left entirely to the schema.

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

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

The first sentence names a specific verb and resource ("Create a draft in the mailbox") and the second immediately scopes the reply variant. An agent can tell this apart from update_draft, get_draft, and send_email without consulting 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?

Usage is only implied: creating a draft rather than sending is inferable from the verb and the sibling names, and the reply branch is described in detail. But there is no explicit statement of when to prefer this over send_email or update_draft, and no prerequisites 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not say whether the deletion is permanent or recoverable, whether a confirmation step is expected, or what happens to a missing/already-deleted draft. With annotations carrying the load, this is thin but not contradictory.

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?

It is a single front-loaded sentence with no filler, so it is structurally clean. But the brevity comes from under-specification rather than tight writing — the one sentence carries almost no information beyond the name.

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 mutation on a draft, and the output schema means return values need not be explained. Still, the description omits permanence/recoverability, error behavior for unknown draft IDs, and any relationship to the trash/restore siblings — information an agent needs before invoking an irreversible-sounding 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?

Schema coverage is only 50%: accountId is documented in the schema, but draftId has no description anywhere. The description does not compensate by explaining that draftId comes from list_drafts/get_draft or what the accountId fallback behavior means in practice. For a required identifier parameter, this is a real 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?

"Delete a draft" names a specific verb and resource, so the basic action is unambiguous. However, it essentially restates the tool name and title without adding any scope detail (e.g., permanent deletion vs. trashing, which draft source it targets), leaving it at the minimum-viable level.

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 versus alternatives. The sibling set includes trash_emails, update_draft, and get_draft, and the description does not clarify whether deleting a draft is permanent or whether trashing is a separate path. No exclusions or preconditions are stated.

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

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

Goes well beyond the readOnly/destructive annotations by disclosing that the default result is metadata plus a resource link, that inline changes the payload, that PDFs get extracted text, and that there is a hard 10 MB limit. It does not say what happens when that limit is exceeded, which is the remaining 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?

Four short sentences, all front-loaded with the default behavior before the optional modes. The 10 MB limit sits at the end where a constraint belongs; 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 already documents return structure, so the description only needs to explain mode-dependent behavior, and it does: default, inline, PDF text, and page ranges. The size limit covers the main failure mode for a binary-bearing read.

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

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

Schema coverage is 60% and the undocumented 'inline' flag is the most consequential parameter; the description explains exactly what it changes. The 'pages' behavior is reinforced with a concrete example (201-400). Only accountId/messageId assumptions (e.g., that messageId comes from a prior email listing) are left implicit.

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

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

States a specific verb and resource: retrieve metadata and a resource link for one attachment. It is clearly distinguishable from email-level retrieval siblings like get_email, though it does not name them 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?

Offers conditional guidance ('with inline, the result also includes the content', 'pages returns the text of a page range'), which tells an agent how to choose between modes. However, it never states when to use this tool versus get_email or get_email_body, nor any preconditions such as needing the attachmentId from message metadata first.

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

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

Goes well beyond the annotations, which already declare destructiveHint=true and idempotentHint=true. The description discloses the resulting subject prefix, that original content is quoted, that attachments are carried over unless includeAttachments is false, where the comment appears, and exactly how idempotent replay behaves.

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

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

Three sentences, front-loaded with the core action and followed by the behavioral details an agent needs. No filler and nothing buried at the end.

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 key behavioral traits of a forwarding mutation. Nearly complete, with only minor gaps such as account-selection prereqs already handled by the schema.

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

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

Schema description coverage is 88%, so the schema already documents to/cc/from/accountId/messageId/idempotencyKey/includeAttachments. The description mostly restates schema facts (attachment default, comment placement) rather than adding new meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('Forward an email to new recipients') and adds the concrete result (Fwd: subject, quoted original). It is distinguishable from send_email by the word 'forward' and the quoted-content behavior, though it never explicitly names sibling 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?

Gives clear operational guidance on retries: repeating a successful forward with the same idempotencyKey and arguments returns the saved result. It does not explicitly rule out send_email or address preconditions, but the usage context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the result is a saved snapshot, and the outcome may be indeterminate ('uncertain outcome'), which matters because an agent must not treat non-success as definitive 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?

A single front-loaded sentence that names the action, the object, and the outcome states with no filler. Slightly more could be said about usage without bloat, but nothing present 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?

An output schema exists, so the return values need not be explained, and the annotations cover safety. However, for a tool requiring an operationId, the definition never explains what an operation is or where to obtain one, leaving a meaningful gap for correct invocation.

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% for two required parameters (accountId, operationId), and the description supplies no meaning for either — it never says where the operationId comes from or how it relates to accountId. The 'send or forward' wording hints at scope but does not compensate for the complete lack of per-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?

States a specific verb (check) and a specific resource (the saved result of a send or forward), and enumerates the outcome space (succeeded/failed/uncertain). It is clear on its own, though it does not explicitly contrast itself with the similarly named sibling get_status.

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 'of a send or forward' implies the tool is used after invoking send_email or forward_email, but there is no explicit when-to-use/when-not guidance, no mention of polling vs. one-shot lookup, and no pointer to an alternative such as get_status.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: it does not say what happens if the draft ID is unknown, whether sending state or scheduled info is included, or how it behaves when multiple accounts are connected.

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 twelve-word sentence with the resource and key front-loaded and no filler. It is not padded, though the brevity leaves gaps that other dimensions penalize.

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 single-resource getter with an output schema and annotations, the essentials are covered. Missing are the failure behavior for a bad draft ID and any mention of the optional accountId scope, which matters given the tool operates in a multi-account 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?

Schema description coverage is 50%: accountId is documented in the schema ('Optional when exactly one account is connected'), while draftId is only named. The description's 'by its draft ID' confirms the required parameter's role but adds no format or lookup semantics, so the schema is doing most of the work.

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 (read) and resource (draft) with the retrieval key (draft ID), which cleanly separates it from create_draft, update_draft, and delete_draft in the sibling list. It does not explicitly name those siblings or contrast itself with them, so it stops short of a 5.

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

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

The word 'existing' implies this is for retrieving a draft you already have an ID for, but there is no explicit when-to-use or when-not statement. No alternative is named, even though update_draft and preview_send operate on the same object and an agent must infer which to call.

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/non-destructive, and the description adds a genuine behavioral trait not visible in structured fields: bodies are capped at 50,000 characters and bodyTruncation indicates continuation points. That is exactly the kind of context that prevents an agent from assuming it got a complete message.

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 what is returned, then the truncation caveat, then the escape hatch. No wasted phrasing.

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 spelled out, and the truncation/continuation contract is covered. The notable omission is the bodyFormat parameter's effect and any pointer to download_attachment for the referenced attachment metadata.

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 only 50%; accountId and includeHeaders are documented in the schema, but messageId and especially bodyFormat (which controls whether text/html/both/none is returned) are described nowhere. The description mentions the body only in the context of truncation and never explains the format switch, so it fails to compensate for the coverage 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?

States a specific verb and resource ('Read one email') and enumerates the payload it returns: recipients, body, attachment metadata. It is clearly distinguishable from list_emails/search_emails and it names the sibling get_email_body as the tool for the truncated remainder.

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 an explicit routing rule: when body content exceeds 50,000 characters, call get_email_body for the rest. It does not discuss when to prefer get_thread or search_emails, so the guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that reads are bounded and must be continued via offsets, but it omits default/max page size and behavior at end of content.

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

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

Two short sentences, front-loaded with the core action, with zero filler. Slightly penalized because the pagination pointer references a nonexistent parameter name.

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 described. Still, for a 5-parameter tool with only 20% schema coverage, the description leaves format selection, offsets, and limits unclear enough to hinder correct invocation.

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

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

Schema description coverage is only 20% (only accountId is documented), so the description should carry the load but mostly doesn't. Worse, it cites 'nextOffset', which is not an actual parameter name (the schema exposes 'offset'), risking agent confusion, and it never clarifies the required 'format' enum values or what 'maxChars' bounds.

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 ('Read') and resource ('email body') and clarifies the read is partial/bounded. However, it does not explicitly distinguish itself from the sibling get_email, so an agent must infer that get_email returns the full message while this returns a page of the body.

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 pagination guidance ('Use nextOffset to continue'), which implies this is the right tool for fetching a body incrementally. It offers no when-to-use guidance relative to get_email/get_thread, and no prerequisites 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?

readOnlyHint=true already establishes the safety profile, so the description earns credit for adding new information: the response content varies by role (administrators additionally receive plan details) and exposes accounts requiring re-authentication. It does not discuss caching, freshness, or failure modes, keeping 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?

One efficient sentence with the primary resource front-loaded and the admin caveat trailing. Nothing is wasted, though the clause ordering puts the role-dependent nuance after the core claim rather than segmenting it.

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 zero parameters, the description needn't document return shapes, and it covers what the tool surfaces plus the role-based variation. The only real omission is routing guidance versus sibling status/list tools, already penalized under usage guidelines.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema already fully covers the empty input object.

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

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

Names the resource ("Account connection and scheduled-send status") and enumerates the notable contents: re-authentication issues and, for admins, plan details. This is specific enough that an agent can distinguish it from list_accounts or list_scheduled_emails, though it never says so 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?

Usage is only implied — the mention of accounts needing re-authentication hints at a health-check use case, but there is no explicit "use when" or any comparison to the closest siblings (list_accounts, list_scheduled_emails). The agent must infer the invocation context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — that results are paged and capped at 50,000 body characters per page — but says nothing about how to continue paging, what happens at the end, or whether the cap truncates message bodies.

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 tight sentence with the resource and the paging constraint front-loaded; nothing is redundant. It is arguably over-terse, but every word present 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 no explanation, but this is a 5-parameter paginated read with 20% schema coverage and the description leaves pagination mechanics, bodyFormat choices, and pageSize limits entirely undocumented. For a paging tool, the absence of continuation guidance is a material 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 only 20% (only accountId is documented), so the description must compensate and largely fails. It never explains pageToken continuation, the pageSize maximum of 25, or the bodyFormat enum values (text/html/both/none); the 50,000-character statement is the only parameter-adjacent detail.

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 (read) and resource (messages in an email thread) and clarifies that results are paged. It is distinguishable from get_email/get_email_body by its thread-level, paged scope, though it never names those siblings 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?

There is no guidance on when to use this instead of get_email, get_email_body, or search_emails, nor any mention of prerequisites such as needing a threadId obtained elsewhere. Usage is only inferable from the word 'thread'.

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

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

Annotations already declare this as a safe read-only operation, and the description adds useful scope by saying it covers mailboxes this connection can access. It also summarizes returned fields, but that overlaps with the output schema and does not add deeper behavioral details such as ordering or pagination.

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 wasted wording. The purpose is front-loaded and the return summary follows efficiently.

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 listing tool with an output schema and annotations, the description is complete enough. It states what is listed and what each entry contains without needing to duplicate schema 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?

The tool has zero parameters, so parameter semantics are not a concern. The description does not need to explain inputs, and the baseline for no-parameter tools 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 states a specific verb and resource: listing connected mailboxes accessible to this connection. It is clearly distinct from email/folder-oriented siblings, though it does not explicitly name an alternative such as list_send_as.

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 'this connection can access,' suggesting it is for discovering available mailbox accounts. However, there is no explicit when-to-use guidance or comparison with sibling listing 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds that results include metadata and optional previews and that pagination uses pageToken, but it does not add deeper behavioral context such as rate limits, auth needs, or default result 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 three short sentences, front-loads the core purpose, then adds filtering/pagination and the sibling handoff. There is no wasted text and the structure is easy for an agent to scan.

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 16-parameter list/search tool with an output schema, the description is minimally adequate: it covers the core operation, previews, pagination, and get_email handoff. It remains incomplete on when this tool should be preferred over search_emails and does not give enough guidance to navigate the broad filter surface.

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 63%, so the schema carries substantial parameter documentation. The description maps several parameters into semantic categories ('folder, sender, read state, dates', pageToken, previews), but with 16 parameters it leaves several important filters like subject, attachment state, account selection, and provider-native queries unaddressed beyond the schema.

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

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

The description gives a specific verb and resource ('List or search emails in a mailbox') plus scope: metadata, optional previews, filtering, and pagination. It distinguishes itself from get_email by directing full-body retrieval there, but it does not distinguish itself from the overlapping search_emails or search_emails_batch 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 explicitly says to use get_email for full bodies, which is useful routing. However, it does not explain when to use list_emails versus search_emails/search_emails_batch, and the filtering context is only implied rather than stated as clear when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that returned folders include standard roles like inbox, sent, drafts, trash, spam, and starred, but it does not mention ordering, pagination, or whether folder hierarchies are included.

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 efficient sentence with the resource and role examples front-loaded. It is appropriately sized for a simple list operation, though there is no separate when-to-use or caveat sentence that would improve structure.

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 listing tool with one optional parameter, a complete output schema, and safety annotations, the description is largely sufficient. The main omission is any routing guidance relative to list_labels, which matters given the sibling tool set.

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 single optional accountId parameter is fully documented in the schema. The description does not add any meaning about accountId or default account behavior, so it sits at the baseline for a well-covered 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?

States a specific verb ("List") and resource ("folders in a mailbox") and adds useful role examples such as inbox, sent, and starred. It does not differentiate itself from the sibling tool list_labels, which is a likely source of confusion for an agent choosing between folder and label concepts.

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 guidance on when to use this tool versus alternatives such as list_labels or list_emails. Usage is only implied by the name and the mention of mailbox folders, and the close sibling list_labels is not addressed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that the resource is Gmail labels or Outlook categories in a mailbox, which is useful provider context, but it does not disclose any additional behavioral details like system label inclusion or result ordering.

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 no unnecessary words. It conveys the core action and provider nuance efficiently.

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 simple read-only nature, full parameter schema coverage, annotations, and an output schema, the description is nearly complete. The only minor gap is the lack of differentiation from list_folders, which could help an agent choose correctly.

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

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

Schema description coverage is 100%, so the single optional accountId parameter is fully documented in the schema. The description does not add any meaning beyond what the schema provides, which is the baseline expectation when coverage is high.

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

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

States a specific verb and resource ('List the Gmail labels or Outlook categories') and clarifies the provider-specific naming distinction. It is clear what the tool does, but does not explicitly distinguish itself from the sibling list_folders 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 gives no guidance on when to use this tool versus alternatives like list_folders, and no exclusions or prerequisites. It only implies basic usage from 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?

Consistent with readOnlyHint=true, and it adds real value beyond annotations: result ordering (pending first, then past), the statuses returned, the lastError field for failed entries, and the operational caveat that pending sends only fire while the Fluxmail server runs. That last caveat is exactly the kind of non-obvious behavior an agent cannot infer from annotations or 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?

Three short sentences with zero filler: scope and ordering first, then field meaning, then the operational caveat. Each sentence carries distinct information and the essential content 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?

With an output schema present and full schema coverage, the description covers what remains: ordering, status semantics, the error field, and the server-running limitation. Adequate for a simple read-only list tool, though a pointer to cancel_scheduled_email for acting on pending items would close the last 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?

Only one optional parameter (accountId) exists and schema coverage is 100%, so the schema fully documents it. The description adds nothing about the parameter, which is acceptable given the baseline for a fully documented single optional param.

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?

A specific verb and resource: "List scheduled sends" plus the exact status taxonomy (pending, sent, failed, canceled) makes the scope concrete and clearly distinct from list_emails or search_emails. It never names a sibling tool explicitly, so the differentiation is inferred rather than stated.

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

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

The description gives enough context to imply when this applies (checking scheduled/failed sends, diagnosing failures via lastError), but it offers no explicit when-to-use versus when-not-to-use guidance and does not reference cancel_scheduled_email for acting on pending entries or list_emails for regular mail.

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 establish readOnly, non-destructive, closed-world semantics, so the safety profile needs no repetition. The description adds only the per-mailbox scoping concept and says nothing about ordering, pagination, or whether this reflects verified/aliased addresses.

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 front-loaded sentence with no filler. It is appropriately short but borders on under-specified rather than effortfully concise.

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 the lone parameter well documented, the core call mechanics are covered. What is missing is the connective context — that these addresses are the valid 'from' values for sending tools — which matters for correct downstream use.

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% and the single optional accountId parameter is fully documented ('Optional when exactly one account is connected'). The description adds no further parameter meaning beyond implying mailbox scoping.

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?

Names a specific verb ('List') and resource ('sender addresses'), scoped to a mailbox. It is clearly distinct from list_accounts, list_folders, and list_labels, though it does not name those siblings 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?

There is no indication of when an agent should call this versus related list tools, no mention that results feed into send_email/forward_email as the from-address, and no note on behavior when no sender addresses are configured.

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=false, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered; the description adds nothing new such as whether marking read is reversible or what happens to messages not owned by the account. With an output schema present and annotations complete, the description contributes no incremental 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?

One short sentence with no padding, but also no structure or front-loaded scoping information beyond the verb. Brevity here reflects under-specification rather than efficiency.

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 mutates state, but the description never says what changes, whether the operation is batch-limited, or how it differs from the unread counterpart. Annotations and the output schema carry most of the weight, leaving the description far short of what a mutation tool should explain.

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%: accountId's optional-when-single-account behavior and the 1-100 messageIds limit are already documented in the schema. The description adds no 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?

The description 'Mark messages as read' restates the tool name and title almost verbatim, adding no scope, verb nuance, or resource detail. It does not distinguish the tool from the sibling mark_emails_unread, so an agent gains nothing beyond what the name already says.

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 versus alternatives such as mark_emails_unread or archive_emails. There is not even an implied workflow hint (e.g., after reading a message body).

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=false, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of batching limits, whether read state is per-message or per-thread, or what side effects (sync, unread counts) 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?

A single short sentence, front-loaded with the action and resource — no filler whatsoever. It is arguably too terse rather than bloated, but there is no structural waste to penalize.

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 simple two-parameter mutation with annotations and an output schema, so much of the burden is shouldered by structured fields. Still, the description omits any note about what gets changed or the 100-message batch ceiling, leaving the agent to derive behavior entirely from schema and annotations.

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 accountId (optional when one account is connected) and messageIds (1-100 IDs) are fully documented in the schema. The description's plural 'messages' is consistent with the batch array but contributes no additional meaning. 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?

The verb+resource (mark messages unread) is unambiguous, but the sentence is a near-verbatim restatement of the tool name and title, adding no scope detail. It also does nothing to distinguish this from the sibling mark_emails_read beyond the word 'unread'.

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 versus mark_emails_read, nor any note about context (e.g., after reading, for follow-up workflows). The agent must infer the entire selection rationale 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile of this mutation is covered. The description adds only the archive/trash exclusion and says nothing about failure modes (missing folder), whether existing messages are duplicated, or partial-batch behavior. With annotations carrying the main burden, a 3 fits.

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

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

A single sentence with zero filler; the exclusion constraint is packed into the same clause as the action, and nothing is buried or repeated.

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 the annotations plus schema fully cover safety, parameters, and return values, so the short description is largely sufficient. The remaining gap is destination-folder semantics (must it pre-exist, can it be a role/name) which the folder parameter description only lightly hints at.

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 only 3 parameters, and the schema documents folder, messageIds (max 100), and accountId fallback behavior. The description adds no parameter-level detail beyond restating 'move messages to a folder', so the 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 (Move) and resource (messages) with a destination, and the clause 'other than the archive or trash' carves out the domain covered by siblings archive_emails and trash_emails. It stops short of naming those siblings explicitly, so an agent must infer which tool to use for those two cases.

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 genuine when-not constraint ('not archive or trash'), which is more than most definitions offer. However it never names the alternative tools (archive_emails, trash_emails) nor states prerequisites such as whether the destination folder must already exist.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the no-side-effect profile is covered. The description adds value with 'resolved' (implying address resolution / recipient computation), but it never says whether invalid input produces errors or warnings, which is the core behavioral question for a preview 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?

A single front-loaded sentence with no filler. The most important constraint ('without sending mail') is placed at the end of a compact clause and 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?

With 12 optional parameters, an output schema, and strong annotations, the definition is not wrong but is thin. It omits whether the preview reports validation failures or diffs against an existing draft, which is what an agent actually needs to decide to call 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 83%, so parameters are largely self-documenting. The description enumerates the resolved fields (sender, recipients, subject, attachments), which maps loosely onto from/to/cc/bcc/subject/attachments, but adds nothing about draftId, replyToMessageId, replyAll, or accountId. 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?

Names a specific verb and resource set ('Show the resolved sender, recipients, subject and attachments') and clearly distinguishes itself from the sibling send_email with 'without sending mail'. It does not name the alternative explicitly, but the non-sending preview scope is unmistakable.

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

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

Usage is only implied: the phrase 'without sending mail' suggests a dry-run before send_email, but the description never says when to prefer this over just calling send_email, nor whether it should always be called first. No exclusions or preconditions are stated.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description need not restate it. The description adds only the Outlook-category synonym and target context, but does not explain behavior when labels are absent or message IDs are invalid.

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 no filler. It immediately states the action and resource.

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, annotations cover safety and idempotency, the input schema is fully described, and an output schema exists. The description is complete enough for invocation, though it could have added minor routing context against add_labels.

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 parameters are documented in the input schema. The description mentions labels and messages but adds no syntax, format, or constraints beyond what the schema already provides; 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 ("Remove") and resource ("labels, or Outlook categories") plus the target ("messages"). It is clearly distinguishable from add_labels, though it does not explicitly name sibling alternatives.

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

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

The description offers no explicit guidance on when to use this tool versus alternatives such as add_labels, nor does it state prerequisites or exclusions. Usage is only implied by the verb "Remove".

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 idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is covered. The description adds only the source-state context ('out of the trash'); it does not say which folder messages are restored into, whether partial failures are reported, or any permission requirements.

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 filler. It is efficient, though its brevity borders on under-specification for a mutating 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?

An output schema exists, so return values need not be explained, but for a mutation that changes message location the description omits the destination folder semantics and error behavior for messages not in trash — the key facts an agent needs to use 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 accountId (optional when one account is connected) and messageIds (up to 100 IDs) are fully documented in the schema. The description contributes nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb ('move') and resource ('messages') plus the source state ('out of the trash'), so the operation is unambiguous. It does not explicitly name the inverse sibling (trash_emails) or the near-neighbor (move_emails), leaving 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?

Usage is only implied by the phrase 'out of the trash' — an agent can infer this applies to messages currently in trash, but there is no statement of prerequisites, when to prefer move_emails instead, or what happens to messages that are not in trash.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered; the description's real contribution is enumerating the query operators (from:, in:, read, starred, attachments, dates). It does not disclose how the free-text query interacts with the parallel structured fields, nor pagination/result ordering behavior for what is clearly a paginated, 16-parameter search.

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 no filler. It is efficient, though the second sentence is a raw operator list rather than prioritized information about how to combine inputs.

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?

Output schema exists, so return values need no explanation, and the query grammar summary is genuinely useful. But for a 16-parameter search tool with an alternative syntax path (rawProviderQuery) and a structured-filter path, the description omits how these compose and when each is preferred — a material 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 coverage is 63%, so several parameters (to, from, read, starred, subject, hasAttachment) have no schema descriptions; the description partially compensates by listing the equivalent query operators. It does not explain precedence between query, structured filters, and rawProviderQuery, which is the most consequential semantic question for this 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?

States a specific verb and resource ("Search one account") plus the key mechanism ("typed portable syntax"), which tells an agent what the tool does. However, it never names the siblings it sits beside — list_emails and search_emails_batch — so the "one account" scoping is the only implicit 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?

There is no explicit when-to-use guidance: nothing says when to pick this over list_emails, or when to use search_emails_batch for multiple accounts. The only hint is the phrase "one account", which forces the agent to infer the batching alternative from a sibling 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered by structured data. The description adds genuine context beyond that: the batch cap of 20 and the per-account result grouping. It omits important behavior for a fan-out call such as partial failures (what happens if one account errors), per-account pagination via pageToken, and rate-limit 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?

A single front-loaded sentence with no filler; the batch scope and the return grouping both land immediately. It is arguably too terse for a 14-parameter fan-out tool, but that is a completeness problem rather than a structural one.

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 14-parameter, multi-account fan-out operation, the description covers only the account count and result grouping. With 43% schema coverage, an output schema present, and annotations carrying safety, the missing pieces are the ones an agent most needs: per-account pagination semantics, partial-failure behavior, and how the many filter parameters combine with the portable query.

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

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

Schema description coverage is only 43% across 14 parameters, so the description is expected to compensate, but it does not. It mentions only the query ('one portable query') and the accounts cap; it says nothing about the accounts[].pageToken field for per-account paging, pageSize behavior across accounts, or how the filter parameters (from/to/subject/folder/starred) interact with the portable query syntax.

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) plus the distinctive scope (up to 20 accounts in one call) and the return shape (one result group per account), which clearly separates it from the single-account search_emails sibling. It never names that sibling explicitly, so the differentiation is inferred rather than stated.

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

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

The 'up to 20 accounts' bound implies this is the multi-account variant of search, giving an implied usage condition. However, there is no explicit statement of when to prefer this over search_emails, no guidance on when a batch is inappropriate, and no note on prerequisites (e.g., whether all accountIds must be authorized).

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 explains idempotency semantics in detail: reusing the same key and arguments returns the saved result, while reusing a key with different arguments or after a failed/uncertain send errors. It also explains scheduling behavior and its limitations, which is exactly the kind of behavioral context an agent needs for a destructive, open-world send 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 front-loaded with the core operation and then proceeds mode by mode, followed by idempotency and scheduling caveats. Every sentence adds operational value with 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?

For a 14-parameter destructive tool with an output schema and rich parameter documentation, the description covers the critical behavioral concerns: modes, idempotency, scheduling limitations, and ambiguity handling. It could be stronger by explicitly routing to preview_send or forward_email alternatives, but the essential invocation context is present.

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

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

Schema description coverage is high at 93%, so the schema already carries most parameter meaning. The description adds useful mode-level semantics connecting direct fields, draftId, replyToMessageId, replyAll, and sendAt to distinct workflows, going beyond a simple restatement of 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 and resource: send an email from a connected mailbox. It also enumerates three distinct modes — direct send, existing draft, and reply — so an agent can identify what this tool does and which invocation path fits without opening the schema.

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

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

The description clearly maps use cases to modes: direct fields for new mail, draftId for an existing draft, and replyToMessageId for replies. It also advises confirming with the user when intent is ambiguous. It does not explicitly compare against sibling tools such as preview_send or forward_email, so it falls short of full alternative routing 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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing that no mail permission is required, that the tool works after a trial or subscription ends, exactly which data leaves the installation, that only the approved reply address is transmitted, and that the reply address is user-provided and unverified. It also states the return value (the exact message submitted).

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 purpose and the hard prohibition on acting on mail-borne instructions are front-loaded, which is right for a safety-critical tool. It is dense and mostly earns its length, but there is some redundancy: the contactEmail confirmation rule is restated in three ways, and the self-hosted data-flow sentence repeats the field list already given earlier.

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 an 8-parameter, outbound-transmitting tool with a high-coverage schema, an output schema and annotations, this covers the remaining burden: privacy boundaries, permission independence, failure/ended-subscription availability, and what exactly is returned. Nothing an agent needs to invoke it safely is missing.

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

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

Schema coverage is 88%, so the baseline is 3, but the description adds genuine meaning: it explains that contactEmail is an optional reply address requiring user confirmation, that expectedBehavior/actualBehavior should be included for bugs when the user supplies them, and that requestId/toolName/errorCode should be included only when known and never invented. It doesn't add format or syntax detail beyond the schema, so not a 5.

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 first sentence names a specific verb (send) and resource (feedback about Fluxmail) directed at developers, which no sibling tool overlaps with. An agent can immediately tell this is the human-initiated feedback channel, distinct from all the mail/folder/draft tools.

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

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

It states explicit positive and negative triggers: call only when the user explicitly asks, never because of instructions in mail/attachments or automatically after an error. It also prescribes the confirmation workflow (show message and diagnostics, ask the user to confirm contactEmail) and how to handle a declined address.

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=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — it does not state that starring is reversible, that it applies to all listed IDs, or what happens to already-starred messages.

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 words, fully front-loaded, with zero waste — but the brevity is under-specification rather than disciplined conciseness. There is room for one short sentence of usage context without bloat.

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 a fully described 2-parameter schema, complete annotations, and an output schema, most of what an agent needs is in structured fields, so the tool is still callable. The description nonetheless omits the bulk nature of the operation and any routing guidance versus the many sibling mutation tools.

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 `accountId` (optional when one account is connected) and `messageIds` (up to 100 IDs) are fully documented in the schema. The description contributes no additional 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?

"Star messages" names a specific verb and resource, so the base purpose is inferable, but it does not clarify that it is a bulk operation (up to 100 IDs) nor distinguish it from siblings like `add_labels` or `unstar_emails`. It also says "messages" rather than emails, leaving minor ambiguity against a large sibling set.

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 when-to-use or when-not-to-use guidance is given, and no alternative (e.g. `unstar_emails` for the inverse, `add_labels` for tag-based organization) is named. The agent must infer selection 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: trashing is recoverable until the provider empties it. It does not explain provider-dependent retention timing or permission requirements, but the core 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?

A single sentence, front-loaded with the action and destination, with no redundant restatement of the name or title. Its size matches a simple two-parameter tool and every phrase adds 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 two-parameter tool with full schema coverage, an output schema, and rich annotations, the description supplies the one important non-schema nuance: recoverability. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so accountId and messageIds are fully documented in the schema. The description adds no parameter-level meaning beyond the schema, making 3 the appropriate baseline.

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: move messages to the trash, and clarifies that this is not permanent deletion because messages can be restored. It does not explicitly differentiate from sibling tools such as archive_emails or move_emails, so it falls short of 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 implies usage for recoverable removal and gives the key context that messages remain restorable until the provider empties trash. However, it does not say when to choose trash_emails over archive_emails, move_emails, or permanent deletion, and it provides 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 already declare this as a non-destructive, idempotent mutation, and the description adds no behavioral context beyond restating the operation. It does not mention batch scope, account behavior, or any caveats beyond what structured fields provide.

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 sized for a simple toggle operation, though it could include a brief routing hint without sacrificing conciseness.

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, the schema fully documents its parameters, annotations cover safety traits, and an output schema exists. However, the description omits useful context such as the batch limit and the relationship to star_emails, leaving it only minimally complete.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the input schema. The description adds no additional parameter meaning, but baseline 3 is appropriate when the schema carries this burden.

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: 'Remove the star from messages.' It clearly distinguishes the operation from star_emails by the opposite action, though it does not explicitly name that sibling.

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 guidance on when to use this tool versus star_emails or other message-modification tools. The operation is implied by the name and description, but no alternatives or exclusions 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the description is not carrying the safety profile alone. It still adds genuine value by clarifying that the operation is whole-object replacement, which tells the agent that omitted fields are effectively lost rather than preserved — a distinction the annotations do not convey.

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

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

Two short sentences, front-loaded with the verb and the one behavioral caveat that matters. No filler and nothing that duplicates structured fields.

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 12 parameters, an output schema, and rich annotations, the description covers the core semantics but leaves a consequential ambiguity unresolved: whether omitting a field (versus passing null) clears it, and whether attachments are dropped when not resent. For a destructive whole-object replace on an email draft, that gap matters.

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 83%, so the schema already explains recipients, bodyHtml/bodyText, attachments, and replyToMessageId in detail. The description contributes no parameter-level information beyond the general replacement semantics, 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 and resource ('Replace the content of an existing draft') and adds a qualifier that separates it from a patch-style updater. It does not explicitly name siblings such as create_draft or get_draft, so the differentiation comes from the name rather than the prose.

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?

'This is a full replacement, not a patch' implicitly tells the agent it must resend every field it wants to keep, which is real usage guidance. However, there is no explicit when-to-use versus create_draft/delete_draft, no note that draftId is required and must reference an existing draft, and no exclusion of drafts that have already been sent.

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