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

No annotations are provided, so the description carries the burden. It discloses the provider-specific mailbox names ('Archive' for iCloud, 'All Mail' for Gmail), which adds context. However, it does not state whether the operation is reversible, destructive, or requires special permissions, which would be valuable for a mutation tool.

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

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

Two concise sentences that front-load the purpose and then add a relevant detail about provider differences. Every word earns its place, with no redundancy or filler.

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

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

For a simple move operation with one parameter and no output schema, the description is adequate. It covers the core action and the only special case (mailbox naming). It lacks details on error handling or return behavior, but these are not critical for such a straightforward 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?

The single parameter 'message_ref' is well-documented in the schema with a clear description ('Composite message reference from list_emails or search_emails'). Schema coverage is 100%, so the description adds no additional parameter meaning, but the schema already provides sufficient 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?

The description clearly states the action ('Move an email to the Archive mailbox') and specifies the resource and destination. It also distinguishes from siblings like 'move_email' or 'move_to_junk' by explicitly naming the archive destination.

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

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

The description implies when to use this tool (for archiving) and provides provider-specific context (iCloud vs Gmail mailbox names), but it does not explicitly contrast with alternative moves (e.g., 'move_email' or deletion) or state when not to use it.

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

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

With no annotations, the description must disclose behavior. It mentions using a configured local AI model and details the returned JSON fields, providing some transparency. However, it does not state whether the operation is read-only, has side effects, or any prerequisites beyond the model configuration.

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

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

Two concise sentences: the first states the action, the second lists the exact output structure. No redundant information, suitable length.

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

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

For a tool with one parameter and no output schema, the description covers the core functionality and return values. It lacks explicit mentions of prerequisites or edge cases, but the information provided is sufficient for basic usage.

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 single parameter message_ref is fully documented in the schema with a clear description ('Composite message reference from list_emails or search_emails'). The description itself does not add extra meaning beyond the schema, but schema coverage is 100%, 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?

The description clearly states the tool's function with a specific verb ('classify'), resource ('email'), and detailed output structure (category, priority, action_required, tags). This distinguishes it from siblings like summarize_email or triage_inbox.

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

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

The description implies when to use the tool (when an email needs classification into categories and priorities) but does not explicitly mention alternatives or exclusions. However, the clear context of classification provides sufficient 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 of disclosing behavior. It reveals key behavioral traits: 'opens the compose window with a draft' by default and 'sends immediately without confirmation' when send=true. This goes beyond the schema by noting the lack of confirmation, which is critical for the agent.

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 purpose, and every word earns its place. No redundancy or irrelevant details.

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

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

The tool is relatively simple with 5 parameters and no output schema, and the description sufficiently explains the primary behavior. It covers the draft vs send distinction but could optionally mention error handling or response details, though these are not essential.

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 covers 100% of parameters with descriptions, so baseline is 3. The description adds nuance about the send parameter ('without confirmation') and reinforces the default draft behavior, providing marginal value 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 clearly states 'Compose a new email' with a specific verb and resource, and explains the two modes of operation (draft vs send). It effectively distinguishes this tool from siblings like reply_email or draft_reply by focusing on composing a new email.

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

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

The description provides clear context for when to use send=false (draft) vs send=true (immediate send), which is essential for correct usage. However, it does not explicitly compare against sibling tools or state when not to use this 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 the full burden of behavioral disclosure. It usefully reveals idempotency ('reports success if the folder already exists') and the top-level nature of the folder, which are meaningful beyond the schema. It does not detail permissions or side effects, but for a simple create operation this is adequate.

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 purpose. The idempotency note and pairing hint are both relevant and concise. 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 low-complexity tool with 2 required parameters, the description covers purpose, behavior (idempotency), and a related usage pattern (move_matching). It does not explain return format, but that's less critical for a simple create operation, and the 'reports success' phrase hints at the outcome.

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 schema descriptions already explain both parameters ('Name of the new folder' and 'Account to create the folder in'). The description text adds no additional parameter-specific meaning, so the baseline of 3 applies.

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

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

The description clearly states the action ('Create a new top-level mailbox/folder') and the resource ('inside an account'). It distinguishes from sibling tools like create_rule by focusing on folder creation, and the phrase 'top-level' clarifies 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?

The description explicitly pairs this tool with move_matching for filing mail by rule, giving a concrete usage pattern. It does not explicitly state when not to use it or list alternatives, but the context is clear enough since it's the only folder-creation tool among the siblings.

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

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

With no annotations, the description carries full burden and delivers rich behavioral disclosure: real Mail rule with no background process, OR-combining, no touching existing mail by default, idempotent replacement, and destination must exist. This exceeds typical descriptions.

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?

Six sentences, each adding unique information, with the main purpose front-loaded. No filler or redundancy; the 'REAL' emphasis and parenthetical usage are purposeful.

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 no output schema, the description covers key behaviors, side effects, prerequisites, and defaults, enabling an agent to invoke it correctly without additional assumptions.

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

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

Schema coverage is 100%, so baseline is 3. The description adds valuable semantics beyond schema: domains are OR-combined, apply_to_existing controls existing mail, and dest_mailbox must be pre-existing. This justifies above 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?

Description starts with a specific verb and resource: 'Create a native Apple Mail rule that files incoming mail from given sender domains into a folder.' This clearly distinguishes from sibling tools like move_matching or list_rules by emphasizing native automatic rule creation.

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 clear context for when to use: for automatic future mail, with apply_to_existing for current mail, and prerequisite to create_folder. Does not explicitly name alternatives like move_matching for one-off moves, so it misses some exclusion guidance.

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

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

With no annotations, the description carries the full burden. It usefully indicates this is a soft delete (move to Trash) rather than permanent deletion, and notes provider naming differences. However, it does not disclose reversibility, permissions, or effects on related messages/threads, leaving significant gaps.

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

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

The description is a single concise sentence that accurately and efficiently conveys the core action and destination. No redundant or filler content.

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

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

For a simple one-parameter tool with complete schema coverage, the description adequately conveys the operation. Missing details like reversibility and lack of output schema prevent a perfect score, but the core purpose is fully covered.

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 single parameter message_ref is fully described in the schema as a 'Composite message reference from list_emails or search_emails', giving 100% coverage. The tool description adds no additional parameter meaning, so baseline 3 applies.

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

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

The description clearly states the tool moves an email to the Trash, specifying provider-specific terminology (iCloud Deleted Messages, Gmail Trash). This distinguishes it from sibling tools like archive_email and move_email, making the purpose unambiguous.

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

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

No guidance is provided on when to use delete_email versus alternatives such as archive_email, move_to_junk, or move_email. There are no exclusions, prerequisites, or context signals for selection.

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

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

With no annotations, the description carries the full burden. It discloses a non-obvious behavioral trait: the rule is removed but mail is not moved back. This clarifies scope and prevents user misconception, though it omits details like permanence or error handling.

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

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

The description is two concise sentences that front-load the action and resource, then add a useful caveat. Every sentence earns its place with no 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 simple one-parameter tool with no output schema, the description provides the essential details: what it does, how to get valid input, and what the effect is (including what it does NOT do). It is complete given the tool's complexity.

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

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

The input schema already provides 100% coverage for the single parameter with a clear description. The description reinforces the meaning ('by name') and references list_rules, but adds no new semantic details beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the specific action ('Delete') and resource ('Apple Mail rule') plus the key selector ('by name'), which distinguishes it from sibling tools like delete_email and create_rule/list_rules.

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 advises using list_rules to see rule names, which provides clear context on a prerequisite. However, it does not mention when not to use the tool or alternative deletion methods, so it falls short of a 5.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It states the tool uses a local AI model, returns plain text, and crucially does not send. This covers the key side-effect concern. It does not mention potential failures or model-specific nuances, but the core non-sending behavior is transparent.

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

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

The description is two sentences, front-loads the action and resource, and includes the key constraint (does not send) and pointer (ready to pass to reply_email). Every sentence earns its place 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 2-parameter tool with no output schema, the description gives the essential return type (plain text body) and explains the intended next step. It could slightly expand on what 'draft' implies (e.g., no persistence), but the core information needed to invoke and use the tool correctly 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 100%, with clear descriptions for both message_ref and goal. The tool description itself adds no extra parameter-level meaning beyond 'ready to pass to reply_email,' so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Draft a reply to an email'), specifies the mechanism ('configured local AI model'), and explicitly distinguishes itself from the sending operation by noting 'Does not send — use reply_email to review and send.' This disambiguates it from sibling tools like reply_email and compose_email.

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 direct workflow guidance: the output is 'ready to pass to reply_email' and explicitly says not to use this tool for sending, directing users to reply_email instead. This gives a clear when-to-use and when-not-to-use 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 must carry the behavioral burden. It clearly names the action but does not disclose any side effects, permissions, or return behavior. For a simple mutation, this is adequate but not enhanced.

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

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

The description is a single concise sentence with no filler. It fully conveys the tool's purpose in seven words.

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

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

The tool is simple, has only two parameters with full schema descriptions, and no output schema is expected. The description covers the core action, though it could mention that the flag is toggled on the specified message. Overall, it is complete for practical 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 the parameters are fully documented in the schema. The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description 'Set or clear the flag on an email' clearly states the action (set/clear) and the resource (email flag), distinguishing it from sibling tools like mark_read or archive_email. The verb is specific and unambiguous.

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

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

The description implies the tool is used to flag or unflag an email but provides no explicit guidance on when to use it versus alternatives. No exclusions or conditions are mentioned.

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

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

No annotations are provided, so the description carries the burden. It says 'Read' which implies non-destructive, and it specifies what content is returned (headers/body). However, it doesn't explicitly state there are no side effects (e.g., does not mark as read) or address any access or error 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?

Two sentences, front-loaded with the action, and no superfluous information. Every word contributes to understanding the tool's purpose and parameter origin.

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

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

For a simple read tool with one well-documented parameter and no output schema, the description adequately conveys what the tool does and what the output contains. Minor gap: no mention of attachments, message size limits, or error handling, but these are not critical for basic usage.

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 parameter is already well-documented. The description adds some context by restating the source of message_ref, but doesn't provide new syntactic or format details beyond what the schema already gives.

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

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

The description uses a specific verb ('Read') and a specific resource ('full content of a specific email including headers and body'). It clearly differentiates from siblings like list_emails and search_emails by focusing on reading a single email's complete content.

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 that message_ref comes from list_emails or search_emails results, indicating when to use this tool (after obtaining a reference). It doesn't explicitly state when not to use it, but the context is clear enough for basic 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?

Without any annotations, the description carries the full burden of behavioral disclosure. It explicitly says 'Return and clear', revealing that calling this tool consumes/destroys the events. It also explains the empty-array behavior for missing extension or no new mail. This is transparent about the side effect and edge cases, though it could go further to mention whether clearing is atomic or per-user.

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 long, front-loaded with the core action, and contains no redundant or filler text. Every sentence adds critical information: the action, the empty-array condition, and the event fields. This is an appropriately sized and well-structured description.

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

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

For a zero-parameter tool with no output schema, the description is complete: it explains the return value (list of events with fields), covers the edge case of no extension/no mail, and clearly conveys the tool's purpose. There is no missing information that would prevent correct invocation or interpretation.

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 the input schema provides no additional meaning. According to the rubric, baseline for 0 params is 4. The description appropriately adds no unnecessary parameter details and instead focuses on the return value structure, which is more relevant here.

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

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

The description clearly states a specific action ('Return and clear') on a distinct resource ('real-time incoming mail events') pushed by the MailKit extension. This distinguishes it from siblings like list_emails or search_emails, which operate on regular email messages rather than event streams.

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

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

The description provides clear context: it is for polling real-time events from the MailKit extension, with an explicit statement about the empty-array case when the extension is missing or no new mail arrives. It does not explicitly mention alternatives, but the resource type (events) is sufficiently distinct from the sibling email/rule tools, making the usage context 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?

Given no annotations, the description discloses useful behavior: messages are returned newest-first with index 1 as the most recent, and summaries include a message_ref. This adds meaningful context about ordering and integration, though it does not mention read-only status or rate limits.

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

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

The description is three sentences, front-loaded with the primary action, then return value details, then ordering. Every sentence adds value without redundancy, making it appropriately concise and well-structured.

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 listing tool with no output schema, the description explains the return format (summaries with message_ref), pagination, and ordering. It does not cover error handling or rate limits, but for the simplicity of the operation, it is sufficiently complete.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description's mention of newest-first ordering reinforces the offset semantics already present in the schema, but it does not add new parameter-specific information beyond what the schema provides.

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

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

The description clearly states 'List emails in a specific mailbox with pagination', which is a specific verb+resource with scope. It distinguishes itself from siblings like get_email (single email retrieval) and search_emails (searching) by focusing on listing a mailbox.

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

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

It provides clear context by describing pagination and the return of message_ref for use with other tools like get_email, reply_email, move_email, etc., implying it is the entry point for email workflows. However, it does not explicitly state when to prefer this over search_emails, so it lacks exclusions.

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

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

With no annotations, the description carries the burden. It discloses the return format ('tree of account → [mailbox names]') and implies read-only behavior through 'List' and 'Returns'. It does not explicitly mention side effects or permissions, but for a zero-parameter listing tool this is adequate.

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 action and resource, followed by a concrete usage note. Every word earns its place; no 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 simple zero-parameter discovery tool with no output schema, the description fully covers scope ('all mail accounts'), output structure, and practical usage. It also references dependent siblings, making it complete in context.

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

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

The input schema has zero parameters and 100% schema description coverage by default, so the baseline of 4 applies. The description adds contextual value by explaining how the returned mailbox names will be used in subsequent calls.

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

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

The description uses specific verb 'List' with resource 'all mail accounts and their folders/mailboxes' and explicitly states the return shape as a tree. It differentiates from siblings by noting it should be used before list_emails 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?

It explicitly states when to use the tool: 'Use this to discover exact mailbox names before calling list_emails or search_emails.' It names the dependent sibling tools, giving clear contextual guidance.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait—that the tool returns ALL rules, including ones created outside this tool—which adds value beyond the name. It also implies read-only behavior via 'List'. While it doesn't discuss edge cases or side effects, it's adequate for a simple list operation.

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

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

The description is compact—two sentences—and front-loaded with the core purpose. The additional sentence adds meaningful detail (scope and return fields) without waste. Every word earns its place.

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

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

For a simple no-parameter list tool, the description is complete. It specifies what will be listed, the fields included, and the comprehensive scope. No output schema exists, but the description sufficiently conveys the expected return content. Sibling tools are numerous, but the description clearly carves out this tool's role.

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

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

There are zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are needed. The schema coverage is trivially 100% with no properties, so no compensation is required.

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

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

The description clearly states the tool lists all Apple Mail rules with specific fields (name, enabled state, move-target folder, sender domains). It uses a specific verb ('List') and resource ('Apple Mail rules'), and distinguishes from siblings like create_rule/delete_rule by focusing on enumeration.

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

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

The description implies when to use this tool: to see every rule in Mail, including those not created via this tool. It provides clear context but does not explicitly name alternatives or exclusions. However, the phrase 'shows every rule' effectively differentiates it from other rule-related tools.

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

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

With no annotations, the description carries the burden but only states the core action. It does not disclose potential side effects (e.g., whether the email must exist) or permissions, though the behavior is straightforward and reversible by setting the boolean.

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

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

The description is a single sentence that is front-loaded and contains no wasted words, efficiently conveying the entire purpose.

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

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

Given the tool's simplicity (two parameters, no output schema), the description is sufficiently complete. It does not explain return values, but that is not critical for a read/unread toggle. Lacks context about prerequisites, but the action is self-contained.

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 parameters are fully documented. The description adds no additional meaning beyond what the schema already provides, keeping it at the 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?

The description uses a specific verb ('Mark') and resource ('an email') and explicitly states the two possible states ('read or unread'), which clearly distinguishes it from sibling tools like flag_email or archive_email.

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

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

The description implies the usage context: use when you want to change the read status of an email. No exclusions are needed because no sibling tool overlaps with this action, providing clear context without explicit alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the core action without revealing side effects (e.g., whether the email is removed from the source mailbox, reversibility, or permission requirements). This is a significant gap for a mutation tool.

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

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

The description is extremely concise: two short sentences with the action front-loaded. Every word earns its place, and it includes a practical hint without unnecessary fluff.

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

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

For a simple tool with fully documented parameters and no output schema, the description is minimally adequate. However, it lacks information about return values, error conditions, or side effects, and does not differentiate from similar sibling tools. Given the lack of annotations, more context would improve completeness.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds minor value by advising use of list_folders to discover destination mailbox names, but it does not enhance parameter semantics beyond that.

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

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

The description states a clear action ('Move an email to a different mailbox') with a specific resource (email) and destination (mailbox). It does not explicitly distinguish from sibling tools like move_to_junk or archive_email, but is clear enough to stand alone.

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

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

The description implies when to use the tool (when an email needs to be moved), and it provides a useful pointer to list_folders for finding mailbox names. However, it does not explicitly state when not to use it or how it differs from alternatives like move_to_junk or archive_email.

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

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses the safety guard (required filter), performance differences (fast native bulk move vs. slower per-message), return value (number of messages moved), and potential long runtime on large mailboxes.

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 information-dense and front-loaded with the primary purpose. Every sentence provides necessary context—safety, prerequisites, performance, and return value—without 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?

Given no output schema and complex multi-parameter behavior, the description covers all essential context: required filters, destination existence, limit semantics, return count, and performance caveats. It is complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, with each parameter already having detailed descriptions. The tool description reinforces key semantics (like limit behavior and from_filter matching) but does not add significant new meaning beyond the schema, so 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 explicitly states the tool's function: bulk-moving every email matching given criteria from a source mailbox to a destination in one pass. This clearly distinguishes it from siblings like move_email or archive_email by emphasizing the bulk, criteria-based nature.

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 explicit usage guidance: one call per substring, requiring at least one filter, creating the destination folder first if needed, and explaining when to omit vs. set the limit. This tells the agent exactly how and when to use the tool, including important prerequisites and trade-offs.

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 adds valuable behavioral context by revealing that the mailbox name varies by provider ('Junk' for iCloud, 'Spam' for Gmail). It does not disclose other traits like irreversibility or permissions, so it is adequate but not rich.

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, front-loaded with the primary action, and each sentence provides relevant detail without waste. Excellent 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?

For a simple one-parameter tool with no output schema, the description is practically complete: it states the action, destination, and provider-specific behavior. It lacks only minor details like return value or error cases, which are not essential here.

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

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

Schema description coverage is 100% with message_ref clearly described as a composite reference from list_emails/search_emails. The tool description adds no additional param 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?

The description clearly states the action (move an email) and the target resource (Junk/Spam mailbox of its account). It also differentiates from siblings like move_email and delete_email by specifying the junk/spam destination, including provider-specific naming.

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

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

The description does not explicitly state when to use this tool over alternatives like move_email or archive_email. However, the specific destination and provider behavior imply its usage for junk/spam handling, so it meets the implied-usage threshold.

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

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

With no annotations provided, the description carries the full burden of disclosure. It clearly states the two operational modes (compose window vs. immediate send) and even warns that send=true acts 'without confirmation,' which is an important behavioral trait. It does not mention permissions or reversibility, but these are less critical for a compose/send action.

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

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

The description is two sentences, front-loaded with the core purpose, and efficiently explains the send flag without wasted words. 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?

The tool is simple (3 params, no output schema), and the description covers the essential behavior and both send modes. It does not address potential sibling ambiguity (e.g., draft_reply), which would make it more complete, but otherwise it is sufficient for a task of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The tool description adds nothing about message_ref or body beyond what's in the schema, and its explanation of send essentially repeats the schema. 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 'Reply to an existing email,' which is a specific verb+resource that clearly states the tool's function. It also distinguishes from siblings like compose_email by focusing on replying to an existing message, and from draft_reply by describing the send behavior.

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 the send parameter's behavior, which gives context on how to invoke the tool. However, it does not explicitly mention when to prefer this over alternatives like draft_reply or compose_email, nor does it provide exclusion criteria. The guidance is implied rather than explicit.

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 discloses the output format ('Returns message summaries with message_ref fields') and the filter requirement, but it does not explicitly state that the operation is read-only or describe ordering/pagination behavior. This is a minor gap for a search tool, but not fully transparent.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no redundancy. Every sentence adds essential information: what the tool does, what it returns, and a key usage constraint.

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

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

For a 7-parameter tool with no output schema, the description covers the essential aspects: purpose, filter requirement, scope, and output type. It does not mention ordering or pagination, but the schema already documents the limit parameter. The message_ref mention provides integration context, though it could be more explicit about return value structure.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by grouping filters and emphasizing the 'at least one filter' constraint, which is not explicitly stated in the schema. This guides correct invocation beyond individual parameter descriptions.

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

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

The description clearly states the tool's function: 'Search for emails matching criteria across one or all mailboxes.' It uses a specific verb and resource, and distinguishes itself from siblings by noting it returns message summaries with message_ref fields for use with other tools, which sets it apart from list_emails and get_email.

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

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

The description provides clear usage context by stating 'At least one filter (from_filter, subject_filter, after_date, before_date) should be provided.' This implies the tool is for filtered searches, but it does not explicitly name alternatives or when not to use it, leaving some room for ambiguity versus list_emails.

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

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

No annotations are present, so the description carries the full burden. It discloses that the operation uses a local AI model and returns a summary including required actions, which adds some context. However, it does not mention whether the email is modified, what happens if the model is unavailable, or any permission requirements, leaving significant behavioral aspects undisclosed.

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 composed of two concise sentences that front-load the main purpose and immediately state the output format. Every clause adds value, with no redundant or filler content.

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

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

For a simple tool with one well-documented parameter and no output schema, the description covers the core aspects: what it does, how it works (local AI model), and what is returned. It does not elaborate on edge cases or side effects, but given the simplicity, it is largely complete. A slight gap is the lack of explicit assurance that no modifications occur.

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

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

The schema already provides 100% coverage for the single parameter 'message_ref', including a clear description and example. The tool description adds no extra semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific verb ('summarize') and resource ('an email') with a defined output format (2-3 sentences, plain-text summary). It distinguishes itself from sibling tools like get_email and classify_email by focusing on summarization, not retrieval or classification.

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

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

The description does not provide explicit guidance on when to use this tool over alternatives. It never mentions conditions like 'use for a quick summary' or 'instead of reading full email', nor does it reference any sibling tools. Usage context is only implied through the purpose.

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?

Without annotations, the description handles behavioral disclosure. It reveals the use of a configured local AI model, the bulk nature of the operation, and the output format (JSON array sorted by priority). This gives meaningful insight beyond the schema, though it does not explicitly state that emails are not modified.

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, information-dense sentences covering action, return format, and use case. No filler or redundancy, making it easy to parse quickly.

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

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

For a tool with no annotations and no output schema, the description covers essential aspects: what it does, the AI model dependency, bulk behavior, return format, and use case. It could delve deeper into output structure or side effects, but it is sufficient for initial tool selection and 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?

The input schema includes descriptions for all three parameters (100% coverage), so the description does not need to add parameter details. It mentions 'mailbox' generically but adds no specific syntax or constraints beyond the schema, keeping the baseline at 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 (classify and summarize), the resource (multiple emails from a mailbox), and distinguishes from siblings by emphasizing bulk processing in one call. It specifically says 'multiple emails' and 'one call', which differentiates it from single-email tools like summarize_email.

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 a clear context for usage: 'getting a quick overview of a busy inbox.' However, it does not explicitly mention alternatives or when not to use, so it lacks full exclusionary guidance.

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