Server Quality Checklist

Tool Scores

• list_emails_metadataA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds meaningful behavioral context by emphasizing 'without body content' (privacy/performance implication) and by indicating that email_id is intended for a subsequent get_emails_content call. This provides more than the annotations alone, though it doesn't cover pagination or filtering behavior explicitly.

  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 sentences, the first front-loaded with the core action and scope, the second providing a crucial linkage to another tool. No filler, no redundant restatement of schema or annotations.

  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 has 16 parameters and an output schema, the description does not need to explain filtering or return details. It covers the essential purpose and the relationship with get_emails_content. A minor gap is the absence of any hint that the tool supports rich filtering, but the schema fully covers that, so the description is sufficiently 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?

  Schema description coverage is 100%, so the baseline is 3. The description adds limited semantic value by naming the returned fields (email_id, subject, sender, recipients, date), which implicitly clarifies the meaning of email_id as the key for later content retrieval. It does not explain any specific parameter behavior, but the schema already does that thoroughly.

  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 ('List') with a clear resource ('email metadata') and enumerates the exact fields (email_id, subject, sender, recipients, date). It explicitly distinguishes itself from content-fetching tools by stating 'without body content' and references get_emails_content, making its purpose unmistakable.

  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 indicates when this tool is appropriate (for metadata, not body content) and even specifies a follow-up workflow ('Returns email_id for use with get_emails_content'). It does not explicitly state when not to use it or compare it with sibling tools like list_mailboxes, but the context is strong enough for an agent to infer the primary use case.

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

• list_mailboxesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns folder names, hierarchy delimiters, and flags, which is useful behavioral context beyond annotations.

  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 sentences long, front-loads the purpose, and contains no extraneous information. Every sentence adds value.

  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 an output schema exists (implied), the description adequately covers purpose, use case, and return content. It could mention account prerequisites, but overall is sufficient for a simple listing 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 coverage is 100% with all parameters described. The description adds no additional meaning beyond what the schema provides, so 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 clearly states 'List available mailboxes/folders for an email account' with a specific verb and resource. It distinguishes itself from sibling tools (archive_emails, download_attachment) by focusing on listing rather than modifying or downloading.

  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 mentions 'Useful for discovering folder names before moving emails,' providing explicit context for when to use. However, it does not explicitly state when not to use or compare to alternatives, but the purpose is clear enough.

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

• send_emailA
  4.2/5.0
  Behavior5/5

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

  The description discloses detailed behavioral traits beyond annotations: per-recipient SMTP delivery status (succeeded/failed/unknown), independent handling of the Sent-copy outcome, and no automatic retry for ambiguous effects. This significantly enriches the safety and operational understanding beyond the simple write intent implied by readOnlyHint=false.

  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 dense sentence that front-loads the primary action, briefly mentions reply threading, and then provides crucial delivery report details. Every clause adds value with no repetition or 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?

  The description covers the core action, reply threading, and complex delivery reporting, which are essential for a sending tool. It does not mention environment dependencies (e.g., allowed recipients, attachment path resolution) that might be relevant, but the output schema exists and the description is strong overall.

  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% parameter description coverage, so the schema already explains all 11 parameters. The description does not add any parameter-specific details beyond the schema, meriting the baseline score of 3.

  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 ('Send one email using the specified account') and adds the capability of reply threading. This distinguishes it from sibling tools that list, retrieve, save, or delete emails.

  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 usage by stating the action ('Send one email'), but it does not explicitly mention when to use this tool versus alternatives (e.g., save_to_mailbox, list_available_accounts). No exclusions or prerequisites like allowed recipients are mentioned, though sibling tools (list_allowed_recipients) suggest such constraints exist.

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

• mark_emails_as_readA
  4.3/5.0
  Behavior4/5

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

  With annotations already indicating mutating (readOnlyHint=false), idempotent, non-destructive, and open-world behavior, the description adds valuable specifics: 'Partial or ambiguous effects report per-ID succeeded/failed/unknown status and are not retried automatically.' This goes beyond the structured annotations by explaining failure semantics and lack of auto-retry, though it does not discuss auth or rate limits.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the core action, then a useful alternative equivalence, a prerequisite, and a concise note on partial/failure behavior. Every sentence earns its place with no redundancy or filler.

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

  Completeness5/5

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

  The tool has a modest parameter set, clear annotations, and an output schema (signaled by 'has output schema: true'), so the description need not restate return structure. It covers the key workflow step (list first), the behavioral nuance (partial statuses, no retries), and the relationship to set_email_flags, making it sufficiently complete for an agent to invoke 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 fully documents each parameter. The description adds context by saying 'by email_id' and instructing to use list_emails_metadata first, reinforcing where email_ids come from, but it does not add new semantic detail 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 opens with a specific verb and resource: 'Mark one or more emails as read by email_id.' It clearly distinguishes from sibling tools by noting it is the 'common-workflow equivalent of adding \Seen with set_email_flags,' and references list_emails_metadata as a companion. This leaves no ambiguity about what the tool does.

  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 an explicit prerequisite: 'Use list_emails_metadata first.' It also names an alternative (set_email_flags) and positions this tool as the common-workflow convenience, implying when to choose it. It lacks explicit 'when not to use' exclusions, but the context is clear enough.

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

• move_emailsA
  4.3/5.0
  Behavior4/5

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

  Annotations already convey destructiveness and non-idempotency, so the bar is lower. The description adds useful context beyond annotations: partial or ambiguous effects are reported per-ID with succeeded/failed/unknown status, and operations are not retried. This gives the agent a clear picture of outcome handling.

  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 sentences long, front-loaded with the core action, and every sentence contributes value (prerequisites and outcome behavior). No redundant or extraneous content.

  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?

  Despite having no output schema visible, the description covers the key operational aspects: the action, the required prior calls, and how failures are reported. For a mutation tool with partial effects, this is complete and actionable.

  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 baseline is 3. The description does not add significant parameter-level meaning beyond what the schema already provides (e.g., IDs come from list_emails_metadata). It is adequate but not exceptional.

  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 (move) on a specific resource (emails) with a destination (between IMAP folders). This clearly distinguishes it from siblings like delete_emails, archive_emails, and set_email_flags.

  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?

  It explicitly directs users to call list_emails_metadata and list_mailboxes first, establishing clear prerequisites. However, it does not explicitly contrast with alternatives (e.g., when to delete vs. move), so it earns a 4 rather than a 5.

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

• set_email_flagsA
  4.3/5.0
  Behavior5/5

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

  Beyond annotations, the description discloses unsupported flags (\Deleted, provider-specific), partial/ambiguous effects with per-ID status reporting, and no automatic retries. These are valuable behavioral traits that help the agent anticipate edge cases and errors.

  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 compact sentences: the first states the core action and scope, the second lists supported/unsupported flags, and the third covers prerequisite and failure behavior. Every sentence is informative and there is no redundancy.

  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?

  Given the output schema and annotations, the description covers essential purpose, constraints, prerequisites, and failure modes. It is complete for a mutation tool with partial effects, and it does not need to explain return values because the output schema is provided.

  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 coverage is 100% and every parameter has a clear description. The tool description adds only the prerequisite to use list_emails_metadata first, which indirectly relates to email_ids, but does not significantly enrich parameter semantics 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 states 'Add or remove approved IMAP flags on one or more emails by email_id' with a specific verb and resource. It lists the supported flags, clearly distinguishing it from siblings like mark_emails_as_read.

  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 provides a clear prerequisite ('Use list_emails_metadata first') but does not explicitly contrast with sibling mark_emails_as_read for \Seen flag operations. Usage is implied rather than explicitly differentiated, so a model might be unsure whether to use this tool or mark_emails_as_read for read/unread.

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

• download_attachmentA
  4.4/5.0
  Behavior4/5

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

  Beyond annotations (readOnly=false, destructiveHint=true), the description discloses the safe randomized naming, the default directory, the support for explicit paths, and the security-driven settings requirement. This adds meaningful behavioral context not present in the annotations alone.

  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 sentences, each with a distinct purpose: what the tool does, default/explicit path behavior, and the settings requirement. No redundancy or irrelevant detail.

  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?

  Covers the essential context for a download operation: the feature must be enabled, default save location, explicit path support, and source parameters. Output schema exists so return values are not needed. Lacks information about edge cases like file overwrite behavior, but is otherwise complete for an agent to proceed.

  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 baseline is 3. The description adds value by explaining the behavior of save_path (safe randomized name, default directory) and the enable_attachment_download setting, which relates to parameter semantics even though it is not a parameter itself.

  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 immediately states 'Download an email attachment' with a specific verb and resource. It clearly distinguishes this from sibling tools like get_emails_content by focusing on attachment download rather than email content retrieval.

  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?

  Provides clear context on how to use the tool (default save path vs explicit path) and a prerequisite (must be enabled in settings). Does not explicitly mention alternatives or when not to use, but the context is sufficient for an agent to decide when this tool is appropriate.

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

• get_emails_contentA
  4.4/5.0
  Behavior5/5

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

  The description goes beyond the readOnlyHint=false annotation by explaining exactly why the tool is non-read-only: 'because mark_as_read=true changes remote flags.' This discloses a conditional side-effect and clarifies the default behavior (read-only unless mark_as_read is true), providing valuable context that the annotation alone does not convey.

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

  Conciseness5/5

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

  The description is exactly two sentences: the first states the core function, the second adds a usage directive and a transparency note. Every sentence earns its place, with no wasted words, making it highly concise and well-structured.

  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 essential context: what it retrieves, the prerequisite call, and the side-effect behavior. With an output schema present, return values need no explanation. However, it does not explicitly state the max number of emails or that email_ids can be an array, but those details are in the schema. Minor gap in missing explicit mention of multi-email support, but overall adequate.

  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%, and parameter descriptions already explain meaning, defaults, and paging behavior (e.g., body_offset, max_body_length, and the truncation marker). The tool description adds no additional parameter semantics beyond what the schema provides, 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?

  The description clearly states a specific verb+resource: 'Get the full content (including body and reply-thread headers) of one or more emails by their email_id.' It distinguishes this from sibling tools like list_emails_metadata, which presumably returns metadata only, making the tool's unique role obvious.

  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 explicitly instructs to 'Use list_emails_metadata first,' providing a clear prerequisite and implying that list_emails_metadata is for metadata only. However, it does not explicitly state when not to use this tool or compare it to other alternatives like download_attachment, so it misses the full 'when-not/alternatives' guidance needed for a 5.

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

• archive_emailsA
  4.5/5.0
  Behavior4/5

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

  Annotations indicate destructive, non-read-only, non-idempotent behavior. The description adds valuable behavioral context: auto-detection of the Archive folder via RFC 6154 flag with fallback to common names, and that partial results report per-ID status without automatic retry. This goes beyond the annotations, though the annotations already set expectations for destructiveness.

  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 concise with two sentences, no fluff. Front-loads the purpose immediately, then adds key behavioral details. Every sentence adds value.

  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?

  Given the tool's complexity (archiving with folder detection, partial results, prerequisite step), the description covers all essential aspects: what it does, prerequisites, behavior on partial failures, and no need to explain return values since an output schema exists. Fully adequate.

  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?

  The input schema describes all three parameters (mailbox, email_ids, account_name) with 100% coverage. The description adds meaning by specifying that email_ids come from list_emails_metadata and mentioning the folder detection logic, which complements the schema. However, the schema already does most of the work.

  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 the core action: 'Archive one or more emails by moving them to the account's Archive folder'. It uses a specific verb and resource, and the tool name itself matches the description, distinguishing it from sibling tools like list_mailboxes and download_attachment.

  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?

  Explicitly advises to 'Use list_emails_metadata first' as a prerequisite step. It also describes the result reporting behavior for partial/ambiguous effects, implying when to check results. However, it does not explicitly state when not to use the tool or mention alternatives, but given the siblings, the context is sufficient.

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

• delete_emailsA
  4.5/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond the annotations: it discloses the deletion method ('UID EXPUNGE'), the possibility of partial or ambiguous effects, the per-ID succeeded/failed/unknown status reporting, and that operations are not retried automatically. This is exactly the kind of nuance an agent needs to handle a destructive, non-idempotent operation correctly.

  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 exactly two sentences, front-loaded with the primary purpose and method, followed by a concise caveat about partial failures and non-retry. Every sentence earns its place with no redundant or filler content.

  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?

  The description covers the essential context for a destructive tool: what it deletes, how it deletes (UID EXPUNGE), the prerequisite for obtaining email IDs, and the failure semantics. An output schema exists, so detailed return-value documentation is not needed. The description is complete and self-sufficient for an agent to use 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 all parameters are already well-documented in the schema. The description's reference to 'email_id' aligns with the email_ids parameter, and 'Use list_emails_metadata first' matches the schema note, but it adds little new meaning beyond what the structured schema provides. Thus 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 opens with a specific verb and resource: 'Delete one or more emails by email_id using target-scoped UID EXPUNGE.' This clearly states the operation and distinguishes it from sibling tools like move_emails and archive_emails. It also includes a prerequisite ('Use list_emails_metadata first') that reinforces the tool's specific role.

  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 provides a clear usage prerequisite: 'Use list_emails_metadata first.' This tells the agent when it is appropriate to call this tool (after listing metadata). However, it does not explicitly state when not to use this tool or compare it with alternatives such as moving or archiving, which prevents a 5.

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

• list_allowed_recipientsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful operational context beyond annotations by stating that an empty list indicates unrestricted access, which is valuable for interpreting results.

  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, front-loaded with the action verb 'List,' and contains no filler or redundant information. Every word adds value.

  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?

  This is a simple tool with no parameters and an output schema, so the description need not explain return structures. It covers the essential behavior (listing the allowlist) and the edge case (empty when unrestricted), making it fully complete for an agent's decision-making.

  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?

  The tool has zero parameters, so the description has nothing to add regarding parameter syntax or meaning. The schema coverage is 100% (none present), and the baseline for zero parameters is 4, which the description meets.

  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 the specific verb 'List' and names the exact resource, 'configured recipient allowlist,' clearly distinguishing it from the sibling list_allowed_senders. It also states the allowlist's relevance to send_email and save_to_mailbox, making the tool's purpose 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 provides clear context by explaining what the allowlist controls (which addresses send_email can send to and save_to_mailbox can address) and notes the unrestricted empty-list case. It does not explicitly name alternative tools or exclusions, but the context is sufficient for a simple read-only tool.

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

• list_available_accountsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: results are stable, non-secret, and the tool never asks for credentials in chat, plus the empty-result fallback. This goes beyond annotation basics.

  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 sentences deliver purpose, usage rules, and error handling with zero redundancy. Every sentence earns its place, and the description is front-loaded with the key action and subject.

  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?

  With no parameters, an output schema present, and complete annotations, the description fully covers what an agent needs: what the tool does, how to interpret results, and how to handle empty results. No significant gaps remain.

  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?

  Tool has zero parameters, and the schema coverage is 100% (empty properties). The description correctly omits parameter details. Baseline 4 is appropriate since there is nothing to document.

  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 ('List') and resource ('configured accounts') with a clarifying qualifier ('stable non-secret capability records'). This clearly differentiates it from sibling tools like list_mailboxes and list_allowed_recipients, which serve different purposes.

  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 explicitly states how to use the results (accounts with can_receive=true for mail reads, can_send=true for send_email) and provides guidance for the empty-result case (instruct user to run UI/CLI, never ask for credentials). It does not explicitly compare to alternative tools, but the usage context is clear.

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

• list_allowed_sendersA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral context beyond that: it explains that when configured, only allowlisted senders' mail is visible/eligible for other tools, and that an empty list means unrestricted. This helps the agent understand the operational semantics without overstepping.

  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 sentences, front-loaded with the core action, and every sentence adds value—covering what the tool does, why it matters, and the special empty-list behavior. There is no redundant or filler content.

  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 zero-parameter, read-only list tool with an output schema, the description is complete: it states the return type behavior (empty list when unrestricted), the relationship to other tools, and the scope (inbound sender allowlist). Nothing essential is missing.

  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?

  The tool has zero parameters, so there are no parameter semantics to clarify. The description correctly implies that the tool takes no input and simply returns the current allowlist, which aligns with the schema. A baseline of 4 is appropriate given the absence of parameters.

  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 ('List') and a specific resource ('configured inbound sender allowlist'), and clearly differentiates from the sibling tool 'list_allowed_recipients' by focusing on senders. It also explains the functional effect of the allowlist, making the purpose unmistakable.

  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 states clear context: it lists the inbound sender allowlist, explains that it affects which emails are visible/eligible for read and mutation tools, and notes the empty-list behavior when unrestricted. It does not explicitly name an alternative tool, but the context is sufficient for a simple inspection tool.

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

• save_to_mailboxA
  4.9/5.0
  Behavior5/5

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

  The description goes beyond annotations by disclosing specific behaviors: default mailbox/flags, no SMTP dependency, and how ambiguous APPEND responses are handled. These details are not available in the annotations, adding significant value.

  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?

  Each sentence delivers distinct, useful information without fluff. It front-loads the primary purpose, then covers differentiations, defaults, operational context, and an edge case—all in five tight sentences.

  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?

  Given the tool's complexity (12 params, 4 required) and the presence of an output schema, the description covers the necessary context: what it does, how it differs from send_email, when to use it, and notable behaviors. It is sufficiently complete for an agent to decide and invoke correctly.

  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?

  Though schema coverage is 100%, the description adds meaning by explaining parameter relationships (shared with send_email, added mailbox/flags, unsupported reply_to) and the default flag values for mailbox and flags. This helps the agent understand parameter purpose beyond schema descriptions.

  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 clear verb+resource: 'Compose an email and save it to an IMAP folder.' It explicitly contrasts with send_email by noting it shares parameters but adds mailbox and flags, and does not support reply_to, which clearly distinguishes it from the sibling 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?

  It provides explicit usage context by naming send_email as an alternative and stating this is a pure IMAP operation that works without SMTP configuration. The default folder and flags further clarify when this tool is appropriate (e.g., saving drafts not sending).

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