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

With no annotations supplied, the description carries the full burden and does well on the important traits: it is a mutation that is safe to repeat because an existing mailbox is reused, and it discloses the exact return contract (full path read back from Mail, plus created/alreadyExisted booleans). It omits prerequisites such as Mail.app permissions, account existence, and failure behavior when the parent path is invalid.

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

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

Three sentences, front-loaded with purpose then nesting then return contract, with no filler. The phrase 'use its full slash path at the account' is slightly compressed and could be read as ambiguous, which is the only structural blemish.

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?

There is no output schema, so the description appropriately spells out the return values, and it covers the idempotency semantics an agent needs. What remains thin for an unannotated mutation tool is environmental context: permission requirements and error conditions for a non-existent account or parent.

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 already 100%, so the baseline is 3; the description adds beyond the schema by framing the nesting convention (resolve the parent, pass its full slash path at the account) and by implying mailboxName is interpreted as a full path when the parent is omitted. It does not clarify path separator edge cases or whether the account name must match an entry from list_accounts.

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 precise verb+resource: ensure a mailbox (folder) exists in a Mail.app account. The word 'ensure' immediately signals idempotent creation, which is a meaningful distinction from a plain create and cannot be inferred from the name 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?

It gives real operative guidance: for nesting, resolve the parent and pass its full slash path, and it notes that an existing mailbox is reused rather than failing. It does not explicitly point to siblings such as list_mailboxes or get_mailbox_info as the way to resolve or verify a mailbox, leaving that inference to the agent.

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

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

With no annotations present, the description carries the behavioral burden. It adds a useful transparency detail: deleting uses Mail's delete verb and routes to the correct Trash rather than permanently erasing the message. However, it does not mention return behavior, reversibility beyond the Trash implication, or permission/side-effect considerations.

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 sentences with no filler. The primary action is front-loaded, and the second sentence adds a meaningful behavioral clarification about Trash routing. 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 has only three required parameters, all schema-documented, and the description explains the operational routing to Trash. However, it still has gaps: there is no output schema, no indication of what the response looks like, and no guidance on success/failure conditions. This is adequate but not fully 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 input schema has 100% description coverage for all three required parameters, so the schema already documents messageId, accountName, and mailboxName clearly. The description adds no parameter-level meaning beyond 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 a direct, specific action: 'Delete a message.' The operation is unambiguous and distinct from the sibling tools, since no other sibling provides deletion and the closest operations (move_message, flag_message) are clearly different.

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 should be used when a message must be deleted, but it does not explicitly discuss alternatives such as move_message, whether deletion is preferable to moving, or when not to use this tool. Usage context is inferable rather than stated.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the basic set/clear action and optional colour index; it does not explain side effects, whether the operation requires an existing message, whether it is idempotent, or what the response contains.

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

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

The description is short and front-loaded: it states the core purpose in the first sentence and adds the optional modifier in a single second sentence. There is no redundant or distracting 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 flagging operation, the basic action and parameter schema are present, and all parameters are individually documented. However, with no annotations and no output schema, the description does not fully communicate behavioral outcomes or the relationship between flagged and flagIndex, leaving the agent to guess some edge-case behavior.

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. The description only mirrors the optional flagIndex concept and does not add materially to the parameter semantics provided by the input schema.

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

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

The description clearly states the action ('Set or clear the flag') and the resource ('on a message'), and adds the optional flag colour dimension. It is not tautological, though it does not explicitly differentiate itself from sibling tools like mark_read.

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

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

The description provides no guidance on when to use this tool versus alternatives, and does not mention exclusions or related sibling tools. An agent would have to infer the intended context purely from the wording of the schema and sibling names.

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

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

With no annotations provided, the description carries the full burden, and it does meaningful work: it discloses that the tool returns the sender account, and it flags an important behavioral limitation (no new attachments due to Mail.app). It could add more about side effects or failure modes, but the core behavior is transparent.

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

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

The description is three concise sentences. The main action is front-loaded, the return value is specified, and the limitation is stated directly with no unnecessary 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?

Given the schema already covers all parameter semantics, the description is nearly complete: it explains the action, the return value, and the attachment limitation. The only missing piece is explicit routing guidance among the related 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?

All parameters have complete descriptions in the schema, so the description does not need to compensate. It adds useful behavioral context around the sender and attachment limitation, but it does not provide additional parameter-specific details beyond what the schema already contains.

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: forward an existing email message to a new recipient. This clearly distinguishes it from siblings like send_message and reply_to_message because it explicitly describes forwarding an existing message rather than composing a new one or replying to the original sender.

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 usage is implied by the purpose: use this when a user wants to forward an existing message to a new recipient. However, the description does not explicitly mention when not to use it or name alternatives like send_message for new emails or reply_to_message for replying to the sender.

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 "Get" implies a non-destructive read but never says so. It does add genuine behavioral context about the return values — unavailable serverName, port, and usesSsl come back as null, and account type preserves raw Mail values beyond canonical types — yet says nothing about behavior when the account name is unknown or about permissions.

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 purpose and followed by return-value caveats; no filler. The second sentence is somewhat dense with field names, but every clause conveys information the agent would otherwise have to guess.

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 one-parameter read tool with no output schema, the description covers purpose, the lookup key, and the noteworthy null/raw-type quirks of the response. The missing piece is failure behavior for an unknown account name, which would matter for correct 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 description coverage is 100%, so the single accountName parameter is already documented in the schema. The description only restates that lookup is by name, adding no format, casing, or resolution rules for the name. 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?

"Get detailed information about a specific Mail.app account by name" gives a clear verb plus resource and the lookup key, which separates it from list_accounts at a glance. It does not explicitly name the sibling, but the singular-account scope 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?

There is no explicit statement of when to use this versus list_accounts, nor any prerequisite about where the account name must come from. The only implied guidance is "by name," leaving the agent to infer that list_accounts must be called first to discover valid names.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It indicates a read operation but does not describe what 'detailed information' contains, what happens if the mailbox does not exist, whether authentication requires to be ready, or that the operation is safe to call idempotently.

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 or repetition. It front-loads the primary action ('Get detailed information') and scopes it to a specific mailbox. It earns a 5; it just lacks a bit of detail that would make it fully informative.

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?

Although the parameter schema is clear, the description lacks any indication of what the 'detailed information' will contain, and there is no output schema to infer from. It also doesn't clarify why an agent would actually use this tool in the workflow vs list_mailboxes to get names. For a tool expected to return meaningful content, this is a notable gap.

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

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

The input schema covers 100% of the two parameters with clear descriptions ('The name of the account that contains the mailbox', 'The name of the mailbox to retrieve'). The description adds no new semantics beyond the schema, but the schema is complete, so this meets 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 clearly states a specific verb (Get) and a resource ('detailed information about a specific mailbox'), scoped to 'a Mail.app account.' It distinguishes from list_mailboxes implicitly by targeting one mailbox rather than enumerating them, but it never names a sibling tool or explicitly calls out what differentiates it from get_account_detail.

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

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

The word 'specific' implies a use case where the agent already knows which mailbox to query, as opposed to listing mailboxes. However, the description provides no explicit direction on when to use this tool versus list_mailboxes or get_account_detail, and there are no stated exclusions or prerelems.

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 takes the full burden. It discloses that omitting mailboxName searches all mailboxes and notes the performance cost, which is useful. It does not explicitly discuss error handling, output structure beyond high-level fields, or confirm the absence of side effects, but the read-only nature is strongly implied by the operation name.

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 only two sentences, front-loads the core operation, and spends one efficient sentence on the optional parameter. 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 fairly simple read-only-style tool, the description is reasonably complete: it explains the primary call, the optional override, and the kind of result returned. It lacks details on error behavior or exact output structure, but it gives enough 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%, so the schema already explains every parameter. The description adds slight extra context about mailboxName being slower when omitted, but most parameter meaning is already in the schema.

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

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

The description clearly identifies the operation as retrieving a single message by ID and names its major components (body, headers, recipients, attachments). This distinguishes it from tools like list_messages or search_messages, since the focus is on one message's full details.

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

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

The description gives clear context for when the optional mailboxName parameter is useful and why omitting it is slower. It does not explicitly name sibling tools as alternatives, but the usage guidance is contextually sufficient.

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 burden, and it discloses non-obvious normalization semantics: known types are canonicalized while raw Mail type text is preserved, including backend-reported unknown values. It does not describe ordering, pagination, or permission requirements, but for a simple read-only listing this is solid disclosure.

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

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

Two sentences with no filler. The primary capability is front-loaded, and the second sentence adds a genuinely useful caveat about type canonicalization rather than restating the first.

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

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

For a zero-parameter listing tool with no output schema, the description sufficiently explains what is returned and how account types are represented. It is slightly incomplete in not mentioning ordering or whether disabled accounts are included, but nothing critical to correct invocation is missing.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; the baseline for a parameterless tool is 4. The description correctly avoids inventing filtering options that do not exist.

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

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

States a specific verb and resource ('List all Mail.app accounts') and enumerates the returned fields (type, enabled status, email addresses). It is clearly distinguishable from the sibling get_account_detail, which implies a single-account lookup.

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

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

Usage is implied rather than stated: 'List all' signals enumeration versus a detail lookup, but the description never explicitly says when to prefer this over get_account_detail or list_mailboxes. An agent can infer the distinction from sibling names, but no routing guidance is given.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It conveys that this is a listing operation and that download status is returned, but it does not explicitly state whether it is read-only or whether any state is changed.

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

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

One concise sentence that starts with the verb, identifies the resource, and lists the important return fields. There is no redundant or unnecessary content.

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

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

The description is sufficient for a straightforward listing tool with fully documented parameters. It states what is listed and which fields are returned; the main gaps are the lack of an explicit read-only statement and detailed output format, but these are minor for this kind of tool.

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

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

Schema description coverage is 100% for all three parameters, so the schema already explains messageId, mailboxName, and accountName. The description adds no parameter-level meaning, so the baseline score is appropriate.

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

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

The description states a specific verb and resource: 'List all attachments for a message', and enumerates the output fields. It clearly differs from read/save-related siblings by being a listing operation, but it does not explicitly compare against sibling tools.

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

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

Usage is implied: an agent would call this when it needs attachment metadata for a message before reading or saving attachments. However, there is no explicit when-to-use/when-not-to-use guidance, and alternatives such as get_message or read_attachment are not 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?

With no annotations, the description carries the disclosure burden. 'List' conveys a read-only action and the description clarifies the two account scopes, but it does not mention authentication requirements, how empty or invalid accountName are handled, or the exact set of mailbox properties returned. It is adequate for a simple read-only utility but leaves some behavior unspecified.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It presents the main verb and resource first, then the alternative scopes. Every part adds meaningful information.

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

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

For a one-parameter, no-nested, no-output-schema tool, the description is complete. It tells the agent what the tool does and exactly how the one optional parameter affects behavior.",

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%: accountName is already described as the account to list mailboxes for, or omitted for all accounts. The tool description mostly restates this same guidance, so it adds little beyond the schema. Baseline 3 applies because the schema already documents the only parameter.

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 lists mailboxes and defines its two valid scopes: a single Mail.app account or all accounts. The verb-resource pairing is unambiguous and distinguishes it from sibling tools like list_accounts (accounts vs mailboxes) and get_mailbox_info (single mailbox details).

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 by defining the scope, and it explicitly says to omit accountName for all accounts. However, it gives no direct guidance about when to prefer this tool over alternatives such as list_accounts or get_mailbox_info, so usage context is mostly self-evident rather than spelled out.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It communicates that listing is a read operation with pagination, but it does not mention ordering, inclusivity of before/after filters, the shape of the returned results, or any indirect behaviors. This is a meaningful gap for a tool with no annotation support.

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 only two sentences, front-loads the primary action and pagination behavior, and includes no fluff or redundancy. 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?

Given the schema fully describes all parameters and the tool is a straightforward listing operation, the description is mostly adequate. It could be improved by noting the intended pagination flow or expected message chronology, but it is not severely incomplete for an agent to call 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?

The input schema already covers all six parameters with 100% description coverage, including defaults and date formats. The description adds minimal semantic value beyond reaffirming that accountName and mailboxName scope the request, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource ('List messages in a mailbox') and adds the pagination aspect, making the core purpose clear. It does not explicitly distinguish this from sibling tools like search_messages or get_message, so it does not fully earn a 5.

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

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

The description tells the agent to provide accountName and mailboxName, which clarifies the required scope for the operation. However, it gives no guidance on when to choose this tool over related alternatives such as search_messages or get_message.

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 disclosure burden. It states the state change but omits any side effects, return behavior, permissions, or error handling. It does clarify that both read and unread states are supported.

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 front-loads the core action and the full range of intended behavior (read or unread) efficiently.

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

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

This is a simple, well-parameterized tool with fully documented schemas, but the description lacks behavioral context and usage guidance. It is minimally viable but leaves gaps around side effects and selection among siblings.

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

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

The input schema has 100% description coverage, and all four parameters already have clear meanings. The description adds no additional parameter context, so the baseline score of 3 is appropriate.

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

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

The description states a clear verb and resource: marking a message as read or unread. It is specific enough to identify the operation, though it does not explicitly contrast with similar siblings like flag_message.

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

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

The description provides no guidance on when to use this tool versus alternatives such as flag_message or get_message. The context is implied only by the tool name and action.

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 disclosure burden. It does this well by revealing the non-obvious consequence: moving a message adds the destination label but may not remove the original label. It does not, however, describe return values or any side effects beyond the label 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 compact sentences express the operation and its most important caveat without any filler. The main action is front-loaded, and the Gmail label explanation is kept to exactly what the agent needs.

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

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

This is a simple mutating tool with no output schema and no annotations, so the description must carry most of the contextual load. It covers the critical label behavior, but it could additionally mention what the result looks like or when the original label is removed. Still, the core decision-relevant context is present.

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

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

The schema already provides descriptions for all 4 parameters, giving 100% schema coverage, so the baseline is 3. The description adds a little semantic context by explaining what 'moving' means in terms of destination label vs original label, but it does not detail each parameter's meaning beyond what the schema supplies.

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

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

The description uses a specific verb+resource structure ('Move a message to a different mailbox') and immediately clarifies the Gmail label model, which distinguishes this tool from folder-based move operations. It singles out a single message action, which differentiates it from sibling move_messages.

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

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

The context implies this tool is for moving a single message, and the Gmail label caveat gives important situational guidance. However, it does not explicitly say when to use move_message versus move_messages or any other sibling, so the usage guidance is mostly inferred rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the high-level action and an efficiency claim. It does not explain whether the operation removes messages from the source mailbox, what happens if some messageIds are invalid, whether the operation is atomic beyond 'single operation,' or any permission/authorization requirements. This is a meaningful gap for a batch 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 two compact sentences with no filler. The core action is front-loaded, and the second sentence adds practical guidance about efficiency versus the sibling tool. Every word earns its place.

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

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

The tool has a relatively straightforward batch-move operation with all required parameters documented in the schema, but there is no annotations or output schema. The description omits important execution context such as error handling, source-mailbox behavior after the move, or whether the operation is atomic despite the 'single operation' phrase. It is adequate for basic invocation but not fully 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 input schema already describes all four required parameters with 100% coverage. The description reinforces the notion of multiple messages and 'a different mailbox,' but it does not materially expand on parameter semantics or constraints beyond what the schema provides. The baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource—'Move multiple messages to a different mailbox'—and clearly differentiates this batch operation from the alternative move_message by describing it as a single operation and more efficient than calling move_message multiple times. The purpose is immediately 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 clearly sets the context: moving multiple messages at once and doing so more efficiently than repeatedly calling move_message. It does not explicitly spell out when not to use the tool, such as 'for a single message use move_message,', but the efficiency comparison makes the intended use case reasonably apparent.

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 supplied, the description carries the full disclosure burden. It does useful work — declaring UTF-8-only decoding, the accepted MIME/extension set, and extension-based MIME fallback — but says nothing about what happens when the type is unsupported, whether content is truncated or size-limited, or what the response looks like (no output schema exists).

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

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

Three tight sentences with zero filler: capability first, accepted inputs second, alternative tool last. The routing hint is placed where an agent scanning for alternatives will find it.

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

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

For a simple read tool with full schema coverage and no output schema, the description covers the essential decision inputs: what qualifies as readable and where to go otherwise. The remaining gap is error/edge-case behavior for unsupported attachments, which is minor but not trivial given there is no output schema to explain returns.

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 all four required parameters individually documented (messageId, accountName, mailboxName, attachmentName). The description adds no parameter-level meaning such as whether attachmentName is a path, display name, or identifier, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Read ... attachment text inline') plus the content constraints (valid UTF-8) that define the operation. It also explicitly names the sibling it is not ('Use save_attachment for binary files'), so an agent can separate the two without inspecting schemas.

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

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

Gives a clear routing rule: text MIME types and listed extensions go here, binary files go to save_attachment. It enumerates exactly which inputs qualify, but does not say what to do with attachments that fall in neither bucket (e.g., an unlisted text-like extension) or how to discover attachments in the first place.

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 of behavior disclosure. It does disclose the returned value ('sender') and the unsupported attachment behavior, but it does not explicitly state that this sends a message as a side effect or describe the reply content/thread behavior.

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

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

The description is two compact sentences with high information density: the core action, the key return value, and the attachment limitation. There is no filler or redundant restating of the tool name.

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

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

The schema already covers all six parameters, and the description adds the most decision-relevant behavioral facts. It stops just short of fully complete because it does not outline the full return structure or emphasize the potentially irreversible sending side effect, and there is no output schema to fill that gap.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the input schema. The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Reply to an existing email message.' It clearly distinguishes the tool from sending a new message or forwarding by the word 'Reply' and by referencing an existing message, though it does not name sibling tools explicitly.

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

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

Usage is implied rather than explicit: it is for replying to an existing email. It also calls out a meaningful limitation, 'Does not support attachments (Mail.app limitation),' but does not explicitly say when to choose send_message or forward_message instead.

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 supplied, so the description carries the full burden. It usefully discloses that the destination directory is created recursively and that this happens before contacting Mail, but it says nothing about overwrite behavior for files that already exist, what happens when a message has no attachments, or permission/error conditions.

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

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

Two short sentences, front-loaded with the action and free of filler. The ordering detail ('before contacting Mail') is slightly niche but does convey real behavior about partial failure, so it 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?

It states the core action, the destination handling, and the mutation footprint for a 4-parameter tool with full schema coverage. The gaps are return values (output schema absent) and overwrite/duplicate handling, which would round out a write tool with no annotations.

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

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

Schema coverage is 100%, and the schema already documents savePath with its default. The 'creates the destination directory recursively' clause adds real meaning by telling the agent that savePath need not already exist, but that is the only genuine addition beyond the schema.

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

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

The description gives a specific verb and resource: 'Save all downloaded attachments from a message to disk.' The word 'all' implicitly separates it from the singular save_attachment sibling, but it never names that alternative explicitly, so an agent must infer the distinction.

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

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

There is no when-to-use guidance at all. With siblings list_attachments, save_attachment, and read_attachment in the lineup, the definition should say when bulk-saving beats enumerating or saving one attachment, and it does not.

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 behavioral burden, and it does disclose a real side effect plus ordering: the destination directory is created recursively before Mail is contacted, meaning a filesystem write can occur even if the mail operation fails. It omits equally important behavior for a disk-write tool: whether an existing file of the same name is overwritten, and what the tool returns (e.g., the resolved path).

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

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

Two short sentences, both front-loaded: the action first, then the side-effect ordering. Nothing is padded or repeated from the schema.

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 five-parameter tool with full schema coverage, no output schema, and no annotations, the description supplies the one non-obvious behavioral fact (recursive directory creation before the Mail call). Remaining gaps around overwrite behavior are secondary for an agent that just needs 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%, so all five parameters, including the savePath default of ~/Downloads, are already documented in the schema. The description adds no new meaning about path semantics, filename collisions, or how attachmentName is matched, so the baseline 3 applies.

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

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

"Save a specific attachment from a message to disk" gives a concrete verb (save), a concrete resource (attachment), and a destination (disk). The word "specific" implicitly separates it from the sibling save_all_attachments, but that sibling is never named, so the differentiation is inferential rather than explicit.

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

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

Usage is implied rather than stated: the agent can infer this tool is for one attachment while save_all_attachments handles bulk, but no sentence says when to pick one over the other. There is also no guidance on prerequisites, such as whether the attachment must first be listed via list_attachments.

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 supplied, the description carries the full load and does so well: it discloses a 45-second server budget, partial/timeout/skipped/error metadata in the response, and the non-obvious side effect that queued Apple events can outlive process cancellation, including remediation ('wait or restart Mail'). These are exactly the behaviors an agent could not infer from 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?

Four tight sentences lead with the default-safe scope before the cost/constraint, which is the right front-loading. Some phrasing is compressed to the point of being cryptic ('Broad, content or large-mailbox searches'), but nothing is padding.

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 eight-parameter, no-output-schema tool, the description covers the return envelope shape, the timeout budget, and the cancellation caveat, so an agent has enough to call it and interpret failure. It stops short of defining what counts as 'broad' (left to the schema's 1,000-message note) or describing result ordering.

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 eight parameters are already documented, including the field enum and the allowSlow constraint. The description restates only the content-search constraint already present in the field and allowSlow schema entries, adding no new semantics; 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 states a specific verb and resource ('Search one mailbox') and immediately scopes it to single-mailbox, default-safe operation, which separates it from a broad content sweep. It never names list_messages or get_message explicitly, so sibling differentiation is implied rather than stated.

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

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

It gives a clear rule for when the slow path applies: broad, content, or large-mailbox searches 'require explicit allowSlow'. That is genuine when/when-not guidance, though no alternative tool is named for the cases where this one is the wrong choice.

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 supplied, the description carries the full burden and does real work: it discloses that success means 'queued for sending', that 'actual delivery is not confirmed', and how to verify via Sent or Outbox. It stops short of stating that sending is irreversible/unrecallable or what authorization the account needs.

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

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

Three sentences, front-loaded with the action, then the return contract, then the verification step. No filler and no repetition of the name or schema fields.

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

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

For a 7-parameter mutation tool with no output schema and no annotations, the description covers the essential gaps: what a success response contains (`sender`) and that delivery is unconfirmed. Attachment and account-selection behavior is left entirely to the schema, but overall an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so recipient, subject, body, cc, bcc, fromAccount and attachmentPaths are already well documented in the schema, including the fromAccount fallback and error behavior. The description only adds the plain-text constraint on the body, which is a marginal addition over structured data.

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

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

Names a specific verb+resource pair ('Compose and send a new email message') and adds a format constraint ('as plain text'). It does not distinguish itself from siblings like reply_to_message or forward_message, which also send mail, so it falls short of a 5.

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

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

Usage is only implied by the description of composing a new message; there is no explicit guidance on when to use this instead of reply_to_message or forward_message, which are direct alternatives in the sibling list. The only routing hint is about verification (check Sent/Outbox), not about tool selection.

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