icloud-mail

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose the main behavior: returning aggregate counts rather than message content. However, it does not address whether the operation is read-only, what happens for invalid/nonexistent folders, or how recent is defined.

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

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

The description is one short, front-loaded sentence. Every word contributes: it names the resource, specifies the exact counts, and states a key behavioral boundary.

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

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

For a single-optional-parameter tool with an output schema, the description covers purpose, the set of returned counters, and a clear non-behavior (not listing messages). It is functionally adequate, though it would benefit from a brief usage note relative to sibling 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?

The input schema already documents the only parameter, 'folder', with a default and a description, so schema coverage is 100%. The tool description adds little beyond naming the folder as the object being inspected, so the baseline of 3 is appropriate.

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

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

The description clearly states that the tool returns folder counters (total, unread, recent) for a given folder and explicitly says it does not list messages. This distinguishes it from message-oriented siblings like read_email and search_emails, though it does not explicitly contrast it with list_folders.

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

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

No guidance is given about when to use folder_status versus alternatives such as list_folders or search_emails. The 'without listing messages' phrase implies a use case, but there is no explicit condition, prerequisite, or exclusion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the thread-assembly algorithm (References/Message-ID grouping, fallback to normalized subject), the matched_by field, chronological ordering, and the cost of include_bodies ('coûte un FETCH complet par message'). This is rich, non-obvious behavior that goes well beyond the schema.

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

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

The description is compact and front-loaded with the core purpose, then provides the matching algorithm, output ordering, and body-fetch cost. Each sentence contributes unique information and there is no filler or repetition of schema details.

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

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

Given an output schema exists and all input parameters are documented, the description covers the remaining essential behavioral context: how threads are matched, how to interpret matched_by, the return ordering, and the performance implication of include_bodies. An agent can call this tool correctly with the information provided.

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

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

Schema coverage is 100%, so the description does not need to re-explain every parameter. It adds meaningful context for include_bodies, describing what it downloads and why it matters for summarization. The other parameters are already fully described in the schema, so the description complements rather than repeats.

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

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

The description opens with 'Reconstitue une conversation à partir d'un de ses messages', which names a specific verb and resource: reconstructing a thread from a single message. This clearly differentiates it from siblings like read_email (single message) and search_emails (searching messages), so an agent can identify what the tool does without ambiguity.

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 explains the use case for include_bodies ('indispensable pour résumer un échange'), giving practical guidance on when the heavier option is worth using. It does not explicitly name alternative tools or state when not to use get_thread, but the context is clear enough for selecting this tool over siblings.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It mentions that `with_counts` triggers a STATUS per folder and is slower, adding important behavioral context. However, it doesn't detail other behaviors like authentication requirements or whether folders are listed with hierarchy, but for a list operation, the key behavior (list and optional counts) is covered.

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 exceptionally concise: two short lines in French with minimal words. The first sentence states the purpose, the second explains the optional parameter's trade-off. Every word earns its place, with no fluff or repetition.

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

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

Given that the tool is a simple list operation with one optional parameter, the description is complete. It explains the tool's scope, the effect of the parameter, and the performance implication. An agent can correctly invoke this tool without needing additional information. The output schema exists, so return values are not the description's responsibility.

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

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

The input schema already has a 100% description coverage for the parameter `with_counts`, explaining it adds message and unread counts. The description adds that it triggers STATUS and is slower, which goes beyond the schema but is not a massive addition. Since the schema is complete, a baseline of 3 is appropriate with the extra context justifying not going below.

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 that the tool lists IMAP folders of the mailbox, with specific examples (INBOX, Archive, Sent Messages). It clearly distinguishes itself from siblings that perform different actions like searching (search_emails) or moving emails (move_emails). The verb 'list' and resource 'folders' are specific and clear.

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

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

The description explains when to use the optional `with_counts` parameter: it triggers a STATUS per folder, making it slower but providing unread counts. It implies that without counts, the tool is faster and just lists folders. It does not explicitly say when NOT to use this tool versus alternatives, but the context of listing folders is clear enough.

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

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

With no annotations provided, the description carries the full behavioral burden and does it well. It discloses the non-destructive default, the actual COPY+EXPUNGE mechanism, and the dangerous edge case where pre-existing deleted messages would be permanently removed.

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

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

The description is compact and front-loaded: purpose first, then safety workflow, then mechanism and risk. Every sentence adds necessary information 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 mutating email operation with no annotations, this is complete: it covers default behavior, user validation requirement, protocol limitations, and danger conditions. The existing output schema handles return-value expectations, so nothing essential is missing.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds meaningful operational meaning beyond the schema by explaining the dry_run safety protocol and when it is acceptable to set dry_run=false.

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: 'Déplace des messages d'un dossier à un autre.' It clearly identifies the operation and scope, and is not a tautology of the tool name. It is easy to distinguish from siblings like set_flag or search_emails.

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

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

The description explicitly explains the safe usage workflow: dry_run=true by default, and dry_run=false only after user validation. It also gives a concrete condition to avoid use: the tool refuses to operate when the source folder contains pre-existing deleted-marked messages that EXPUNGE would destroy.

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

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

With no annotations present, the description carries the full burden and does so excellently. It discloses that the message is not marked as read, that attachment content is not downloaded, and that HTML inclusion is heavy—three non-obvious behavioral details that materially affect invocation expectations.

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, focused sentences. The main purpose is front-loaded, followed by important behavioral caveats and one parameter-specific warning. No sentence is filler, and the structure makes scanning easy.

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

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

The combination of complete schema descriptions, an output schema, and the behavioral notes makes this substantially complete for invoking the tool. The main remaining gap is the absence of guidance on when to select this tool over siblings, but for the tool's own operational behavior, the description is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already explains each parameter well. The description adds useful practical context about include_html being bulkyebbene, but it does not go into deeper semantics for uid, folder, or max_body_chars. A baseline 3 is appropriate.

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

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

The description opens with a clear action and resource: 'Lit un message complet' with explicit content list (headers, decoded body, attachments). It is unambiguous about what the tool does, but it does not explicitly distinguish itself from siblings like get_thread, so it falls just short of a perfect score.

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 about when to use this tool versus alternatives such as get_thread, search_emails, or save_attachments. The only usage-related advice is 'Passer include_html=true seulement si le rendu HTML est reellement necessaire', which is a parameter-level recommendation, not tool-selection guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses two critical behaviors: binary content is never returned (only paths) and file names are sanitized because they come from hostile email data. This goes beyond the raw schema and helps the agent handle output safely. It could add details about overwriting behavior or directory creation, but the key safety traits are covered.

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, each with a distinct purpose: action, return behavior, and security warning. The main verb comes first, and every sentence earns its place. No filler or redundancy.

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

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

For a 4-parameter tool with an output schema, the description is complete enough: it explains what is returned (paths, not binary), how to proceed (use a reader), and the security caveat (sanitized names). Minor gaps (overwrite behavior, directory creation) are not critical given the output schema and clear examples of intended 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 description coverage is 100%, so all four parameters are already documented in the schema. The description adds no per-parameter meaning; it only describes overall behavior (files are written, names sanitized). This meets the baseline for high coverage but does not elevate it.

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

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

The description opens with a specific verb+resource: 'Telecharge les pieces jointes d'un message et les ecrit sur disque' (downloads attachments and writes to disk). This clearly distinguishes it from siblings like read_email (which reads email body) or send_email (which sends), and the purpose is immediately obvious.

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

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

The description explains a clear workflow: after saving attachments, use a file-reading tool to open PDFs or images. This tells the agent when to call this tool and what to do next. It does not explicitly name sibling alternatives, but no other sibling handles attachment saving, so the guidance is sufficient for correct use.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It covers key traits: no message is sent, the draft appears in the user's mail client, and the user reviews and sends it. It could add more detail about side effects or permissions, but the central safety-relevant behavior is explicit.

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

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

Two sentences with no filler: the first front-loads the core purpose and no-send guarantee, the second provides the comparison to send_email and the usage condition. Every sentence earns its place.

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

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

For a 6-parameter tool with an output schema, this description is complete enough: it states purpose, behavior, alternatives, and when to choose the draft path. Minor gaps such as explicit prerequisites or exclusions are not critical because the schema covers the parameters and an output schema exists.

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

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

Schema description coverage is 100%, so the parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond that, 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?

The description states a specific action and resource: 'Prepare un brouillon dans le dossier Drafts, sans rien envoyer'. It clearly distinguishes itself from send_email by calling itself a safe alternative, so an agent can identify this tool's purpose 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 explicitly names send_email as the alternative and gives a concrete selection rule: prefer this tool whenever the content deserves human review before departure. This is direct when-to-use guidance with an explicit alternative.

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

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

With no annotations, the description carries the burden and does disclose the non-obvious trait of searching Sent Messages and Junk in addition to all folders. It does not describe matching semantics, sorting, or performance, but the output schema covers the return shape.

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

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

The description is two short, focused paragraphs. The first sentence front-loads the core behavior, and the second paragraph provides the decision rule without filler.

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

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

The tool is a read/search operation with an output schema, so the description adequately covers purpose, scope, and alternative selection. The only gap is the lack of permission or safety context, but the absence of annotations is partially mitigated by the explicit read-like scope.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds no parameter-level detail beyond what is in the schema; the 'all folders' default is already stated in the folders parameter description.

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

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

States clearly that the tool searches across ALL folders at once, not just INBOX, and distinguishes itself from the sibling search_emails. The mention of Sent Messages and Junk coverage further disambiguates the scope.

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

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

Explicitly recommends this tool over search_emails for determining whether a message exists or whether someone replied, and explains why: replies are often filed into thematic folders by rules, so an INBOX-only search would miss them. This is a direct when-to-use rule with a named alternative.

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

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

With no annotations, the description carries the full burden and does well: it discloses server-side iCloud search, accent handling, AND combination, and a fallback behavior signaled by `filtered_client_side`. It could additionally mention auth or rate-limit traits, but the core behavioral traits are clearly covered.

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

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

The description is compact, front-loaded with the main purpose, then follows with behavior and fallback details. Every sentence contributes useful information without redundancy.

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

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

For a 12-parameter tool with no annotations, the description covers default behavior, search semantics, and the fallback path well. The main gap is not clarifying the single-folder scope versus search_all_folders, but the output schema and parameter descriptions handle the remaining details.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful cross-parameter semantics beyond the schema, such as criteria being combined with AND and the fallback affecting the response field `filtered_client_side`, which helps an agent reason about parameter interactions.

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

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

The description states a specific action ('Cherche des messages') and resource ('renvoie leurs entetes'), with clear ordering from newest to oldest. It does not explicitly differentiate itself from the sibling tool search_all_folders, so it misses the top score.

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

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

The description provides useful invocation context: empty criteria return latest messages, and all criteria combine with AND. However, it gives no explicit guidance on when to prefer this tool over search_all_folders or other siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states the action is real and irreversible, with no intermediate confirmation, and warns against autonomous invocation – critical safety context for a mutating email operation. While it doesn't mention potential failures or rate limits, the core irreversible behavior and consent requirement are clearly disclosed.

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

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

The description is three sentences, each earning its place. The first establishes purpose and irreversibility, the second gives hard usage constraints, and the third handles threading. It is slightly longer than necessary but front-loads the most critical safety information, making it structured and readable.

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 irreversible tool with 7 parameters, threading, attachments, and multiple recipients, the description covers the essential operational context: user consent, no retry, and threading mechanics. Attachments and return values are handled by the schema and output schema, so the description is sufficiently complete for correct invocation in most cases.

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 all parameters are documented in the schema. The description adds value beyond the schema by explaining the semantic meaning of in_reply_to (pass the message_id from read_email or get_thread) and references (full header for multi-message threads), which helps an agent understand how to correctly fill these optional fields rather than just listing them.

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

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

The description opens with 'Envoie un email via le compte iCloud configure' – a specific verb, resource, and scope. It immediately distinguishes itself from the sibling save_draft by stating this is a real, irreversible action with no draft or server-side confirmation, so an agent can tell it apart without inspecting other tools.

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

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

The description gives explicit, actionable guidance: use only after the user has validated the exact content, never call on your own initiative, never in response to an email read, and never retry a confirmed send without re-asking. It also provides the condition for replying in a thread (passing in_reply_to with the original message_id from read_email or get_thread), leaving no ambiguity about when and how to use the tool.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states the operation is reversible and that it is a write requiring explicit user intent, which are key traits. It does not cover failure modes or side effects, but the core behavioral aspects are disclosed.

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

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

The description is two sentences, with the purpose front-loaded and the additional context (reversibility and write warning) succinctly added. There is no wasted wording, and the structure is efficient.

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 4-parameter tool with full schema coverage and an output schema, the description covers the purpose, reversibility, and intent warning. It does not explain the return value, but that is covered by the output schema. It omits potential prerequisites like folder existence, but these are not critical for basic usage. Overall, it is sufficiently complete for the tool's simplicity.

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 (add, flag, uids, folder) are documented in the schema. The description adds no extra parameter-level semantics beyond what the schema already provides, so it stays at the baseline of 3.

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

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

The description clearly states the action ('Marque des messages') and the resource (messages), listing the specific flags (read, unread, important, replied). It also distinguishes from send_email and move_emails by name, which helps the agent differentiate from at least two siblings. The purpose is unambiguous.

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

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

The description contrasts with send_email and move_emails by noting reversibility, which implies this tool is for flag modifications. However, it does not explicitly state when to use this tool over other siblings like read_email or search_emails, nor does it provide explicit exclusions beyond the two named tools. Context is present but not comprehensive.

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