Server Quality Checklist

Tool Scores

• flag_messageB
  3.1/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• get_mailbox_infoB
  3.1/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• mark_readB
  3.1/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• list_messagesB
  3.3/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• save_all_attachmentsA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry behavioral disclosure. It only states the basic save action and does not explain overwrite behavior, whether directories are created, what happens when there are no attachments, or the shape of the outcome. The term 'downloaded' is also ambiguous and could mislead the agent about whether the tool fetches attachments or only saves already-fetched ones.

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

  Conciseness5/5

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

  The description is a single concise sentence that clearly conveys the core operation without repetition or fluff. It front-loads the action and resource, making it easy to scan.

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

  Completeness3/5

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

  For a simple save-all operation, the schema covers the input side adequately. However, with no annotations and no output schema, the agent would benefit from knowing about return values, overwrite behavior, or directory creation. The description is minimally sufficient but leaves those operational details unspecified.

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

  Parameters3/5

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

  The input schema already provides 100% documentation for all four parameters, including a default value for savePath. The description adds no parameter-level detail beyond the schema, 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.

  Purpose5/5

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

  The description uses a specific verb ('Save') and identifies both the resource ('all downloaded attachments from a message') and the destination ('disk'). It also distinguishes itself from the singular sibling tool 'save_attachment' by the word 'all'.

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

  Usage Guidelines3/5

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

  The description implies this is the batch counterpart of 'save_attachment', but it never explicitly says when to choose it over alternatives like 'save_attachment' or 'list_attachments'. There is no mention of a single-attachment fallback or when bulk saving is appropriate.

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

• save_attachmentA
  3.5/5.0
  Behavior2/5

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

  There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only says the attachment is saved 'to disk,' but does not disclose whether existing files are overwritten, whether directories are created, required permissions, or what the tool returns on success or failure.

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

  Conciseness5/5

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

  The description is a single front-loaded sentence with no filler, repetition, or unnecessary detail. It communicates the core operation immediately and every word is functional.

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

  Completeness3/5

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

  For a relatively simple tool with full schema coverage, the description is close to sufficient. However, given the absence of an output schema and annotations, an agent receives no guidance about return values, overwrite behavior, or potential error conditions, which leaves some real gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all five parameters are already documented in the schema, including the default for savePath. The description adds no extra parameter-level semantic detail, safely resting at the baseline given full schema coverage.

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

  Purpose5/5

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

  The description clearly states a specific action ('save') on a precise resource ('a specific attachment from a message') and its destination ('to disk'). It also differentiates itself from sibling tools: 'specific' excludes save_all_attachments and 'save' distinguishes it from read_attachment.

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

  Usage Guidelines3/5

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

  The description gives a clear intent — saving a single attachment — so an agent can infer when to use it. However, it does not explicitly mention alternatives such as save_all_attachments for saving every attachment, read_attachment for just viewing, or any when-not-to-use conditions.

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

• list_attachmentsA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• reply_to_messageA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• delete_messageA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• move_messagesA
  3.7/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• create_mailboxA
  3.8/5.0
  Behavior2/5

  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. Beyond stating that it creates a mailbox and supports nesting, it does not mention required permissions, behavior on duplicate mailbox names, whether changes are immediately visible, or what happens on failure. For a mutation operation, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single sentence that earns its place: it names the verb, the object, the application context, and the nesting capability. There is no filler or repeated information.

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

  Completeness4/5

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

  For a simple create operation with only three parameters, full schema coverage, and no output schema, the description is sufficiently grounding. It defines the operation and the nesting choice, and the schema fills in the required fields. Additional context about errors or side effects would be nice but is not critical for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter already explained meaningfully in the input schema. The mention of top-level vs nested mailboxes in the description aligns with parentMailboxName but adds little beyond what the schema already communicates, so the baseline 3 is appropriate.

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

  Purpose5/5

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

  Description uses the specific verb 'Create' and resource 'new mailbox (folder) in a Mail.app account', making the action and target unmistakable. The additional 'Can create top-level or nested mailboxes' captures the key variation and clearly differentiates it from sibling tools like list_mailboxes and get_mailbox_info.

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

  Usage Guidelines4/5

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

  The description gives useful context about what the tool can do, including top-level vs. nested creation, which maps directly to the optional parentMailboxName. It does not explicitly compare to alternatives, but none of the sibling tools perform mailbox creation, so clear exclusion language is not necessary.

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

• get_account_detailA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the burden of behavioral disclosure. 'Get' communicates a read-only intent, but the description does not mention error handling, missing-account behavior, or what exactly the detailed information contains.

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

  Conciseness5/5

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

  The description is a single concise sentence with the verb and core focus first. It contains no filler and is immediately skimmable.

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

  Completeness4/5

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

  The description is sufficient for a simple single-account getter by name. However, since there is no output schema and no annotations, the agent is left guessing what the detailed information body includes.

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

  Parameters3/5

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

  The schema provides 100% coverage of the only parameter, accountName, explaining what it is. The description's phrase 'by name' repeats this without adding new detail, so it adds little beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb 'Get' and clearly identifies the resource as a detailed account information for one Mail.app account by name. It distinguishes itself from the sibling list_accounts by emphasizing 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.

  Usage Guidelines3/5

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

  The description implies this should be used when the agent wants details for one specific account rather than listing accounts. However, it does not explicitly mention alternatives or conditions for 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.

• list_accountsA
  3.9/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It states 'List' but does not explicitly confirm it's read-only, idempotent, or safe. No mention of auth, rate limits, or side effects. For a simple list operation, this is a notable gap.

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

  Conciseness5/5

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

  Single sentence with no redundancy. Essential information is front-loaded: verb, resource, and what details are provided. Every word adds value.

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

  Completeness3/5

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

  Given no output schema, the description omits return format (e.g., array of objects). It adequately describes what is listed but not how results are structured. Could improve by noting output shape.

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

  Parameters4/5

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

  No parameters exist; schema coverage is 100% trivially. Baseline for zero parameters is 4. Description adds no parameter info but doesn't need to.

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

  Purpose5/5

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

  Description clearly states verb 'List', resource 'all Mail.app accounts', and specifies included fields (type, enabled status, email addresses). It uniquely distinguishes this tool from siblings which operate on mailboxes, messages, and attachments.

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

  Usage Guidelines4/5

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

  Description implies usage context: retrieving account information. No explicit when-to-use or alternatives, but given the tool's simplicity and no sibling with similar function, it's clear. Lacks prerequisites or exclusions.

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

• list_mailboxesA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• forward_messageA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_messageA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• move_messageA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• send_messageA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description must do the work of explaining behavior. It is transparent about the asynchronous nature of sending: success indicates only that the message is queued, not delivered, and the message may be found in Sent or Outbox. This adds real behavioral context beyond the basic 'send an email' understanding.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core action, then adds the two most important non-obvious behaviors: queued success and delivery verification. Every sentence contributes meaningful information with no fluff or redundancy.

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

  Completeness4/5

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

  The description covers the most critical contextual need: understanding the difference between a queued send and actual delivery, and knowing where to verify the outcome. Combined with a fully documented input schema, this is sufficient for an agent to call the tool correctly. It could be even more complete by explicitly naming another send-related sibling, but that is a minor gap.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the parameters are already well documented individually. The description itself adds little param-specific meaning beyond indicating the message body is plain text, which is minor. Thus the baseline of 3 applies.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Compose and send a new email message as plain text.' This clearly identifies the tool's main action and differentiates it from sibling tools like reply_to_message, forward_message, move_message, etc. It also adds the unique nuance that sending is only queueing, which further defines the purpose.

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

  Usage Guidelines3/5

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

  The tool is clearly for new outbound email messages, and the description provides a useful follow-up instruction to check Sent/Outbox for delivery verification. However, it does not explicitly address when to avoid this tool and choose a sibling such as reply_to_message or forward_message, so the alternative-routing guidance is only implied.

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

• read_attachmentA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description itself must carry behavioral clarity. 'Read' clearly indicates a non-mutating operation, and the supported-types list plus the binary fallback directive reduce unexpected failures. It does not discuss details like error behavior or output size, but the core behavior is sufficiently transparent.

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

  Conciseness5/5

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

  The description is two short sentences that immediately state the action and scope, then provide the alternative for binary files. 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.

  Completeness4/5

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

  Given the tool's simplicity, the description covers the essential routing information and explicitly defines what the tool reads. Although there is no output schema and the return format isn't formally detailed, the phrase 'text content' adequately conveys the expected output for an agent.

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

  Parameters3/5

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

  The input schema already documents all four parameters with descriptions, giving 100% schema coverage. The description adds no additional parameter-level meaning beyond pointing out that the attachment should be a text-based file, so a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific action and resource: 'Read the text content of a text-based attachment inline.' It further clarifies scope by listing supported extensions and distinguishes itself from save_attachment, so an agent can easily recognize this as the inline text-reading tool.

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

  Usage Guidelines5/5

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

  The description provides explicit usage boundaries by enumerating supported text formats and explicitly directing binary files to 'Use save_attachment for binary files.' This tells the agent exactly when to use this tool and when to use the alternative.

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

• search_messagesA
  4.6/5.0
  Behavior5/5

  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, and it delivers: it warns about IMAP full message downloads, timeouts, and that Mail.app loads all matching messages into memory before applying the limit. These are exactly the non-obvious, failure-prone behaviors an agent needs to know before calling the tool.

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

  Conciseness5/5

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

  Three dense sentences, front-loaded with purpose before caveats, and every clause earns its place — no filler, no repetition of schema properties, and the warnings are stated in operational terms agents can act on.

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

  Completeness4/5

  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 and no annotations, the description covers the critical surfaces: performance risks, timeout conditions, and mitigation strategies. Its only gap is that it never hints at the return shape (for example, what fields the returned messages include or their ordering), which is more apparent because no output schema exists.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds real parameter-level meaning beyond the schema: it explains the tradeoff between the field values (fast metadata lookup vs slow, unreliable body search) and how mailboxName/accountName mitigate timeout risk. This turns the enum into a decision rather than just a list of choices.

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

  Purpose5/5

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

  The opening clause 'Search messages by subject, sender, or content' states a specific verb, resource, and the exact fields the tool supports, leaving no ambiguity about what it does. This scope also naturally differentiates it from read-only siblings like list_messages and get_message without needing to name them.

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

  Usage Guidelines4/5

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

  The description gives explicit operational guidance: prefer 'subject' or 'sender' fields because they are fast metadata lookups, avoid 'content' when possible because it is slow and can time out, and always narrow with mailboxName/accountName. It does not name an alternative sibling tool for when a plain listing would be a better fit, so the exclusion guidance is incomplete.

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