Server Quality Checklist

Tool Scores

• search_emailsC
  2.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but discloses no behavioral traits. It does not confirm the read-only nature of the operation, explain result pagination, describe return format, or note performance characteristics of IMAP searches.

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

  Conciseness2/5

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

  While brief, the description is under-specified rather than efficiently concise. The single sentence fails to earn its place due to extreme vagueness, leaving critical gaps for a tool with 3 parameters and no output schema.

  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?

  Inadequate for the complexity level. With no output schema and no annotations, the description should explain what the tool returns (message IDs? full content? metadata?) and how it fits into the email workflow, but it provides none of this context.

  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%, establishing a baseline of 3. The description mentions 'criteria' which aligns with the parameter name, but adds no semantic detail beyond what the schema already provides (IMAP syntax, examples, defaults).

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

  Purpose2/5

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

  The description 'Search emails with criteria' essentially restates the tool name with minimal elaboration. It fails to distinguish this tool from siblings like 'get_email' or clarify the scope of the search operation.

  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?

  No guidance provided on when to use this tool versus alternatives (e.g., 'get_email' for specific retrieval), nor any prerequisites or exclusions mentioned.

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

• send_replyC
  2.3/5.0
  Behavior1/5

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

  No annotations are provided, yet the description discloses nothing about behavioral traits: whether the email sends immediately or saves as draft, whether the original message gets marked as 'replied', threading behavior, or handling of HTML vs. text bodies. For a 6-parameter mutation operation, this is a significant disclosure gap.

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

  Conciseness3/5

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

  The description is extremely brief at four words, which prevents verbosity, but this brevity results in under-specification rather than efficient information density. The single sentence fails to 'earn its place' by not delivering value beyond restating the tool name.

  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?

  For a mutation tool with 6 parameters (including dual body formats and threading controls) and no output schema, the description is inadequate. It omits critical context about email threading, the relationship to the original message, and what constitutes a valid reply versus other message types.

  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, documenting all parameters including the distinction between body_text and body_html. Since the schema fully documents parameters, the description's silence on parameter semantics meets the baseline expectation, though it adds no additional context about the relationship between parameters (e.g., that reply_to_message_id links to the parent thread).

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

  Purpose3/5

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

  The description states the basic action (reply) and resource (email), but fails to distinguish from siblings 'send_email' and 'send_forward'. Given these alternatives, the description should clarify that this creates a threaded response to an existing message versus creating a new conversation or forwarding.

  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?

  No guidance provided on when to use this tool versus 'send_email' or 'send_forward', nor any mention of prerequisites like requiring a valid message ID from an existing email. The description offers no selection criteria for an agent choosing between the three send-related tools.

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

• get_emailC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, yet the description fails to disclose read-only safety, the 'anyOf' parameter logic (requiring either message_id OR uid), or what the 'detailed information' output contains. It leaves the agent guessing about prerequisites and return structure.

  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 extremely brief (4 words) with no wasted text, but it is undersized for the tool's complexity (4 parameters with conditional requirements). However, it earns points for front-loading the core action without filler.

  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?

  Given the parameter complexity (anyOf constraint between message_id/uid), lack of output schema, and absence of annotations, the description is inadequate. It fails to explain the mutual exclusivity logic or hint at the return format, leaving critical gaps in the agent's understanding.

  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?

  With 100% schema description coverage, the parameter meanings are already clear from the schema (folder, message_id, uid, include_body). The description adds no additional parameter context, meeting the baseline for high-coverage schemas.

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

  Purpose3/5

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

  The description states the basic verb ('Get') and resource ('email information'), but 'detailed' is vague—it doesn't specify what data is returned (headers, body, attachments) and doesn't differentiate from sibling 'search_emails' which also retrieves email data.

  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?

  No guidance provided on when to use this single-email retrieval vs 'search_emails', nor does it mention that message_id or uid must be obtained from elsewhere (like list_folders or search_emails) before calling this tool.

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

• send_forwardC
  2.6/5.0
  Behavior2/5

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

  No annotations provided, yet description fails to disclose critical behavioral traits: whether the original email is included automatically, if the operation sends immediately or creates a draft, side effects on the original message, or error handling when original references are missing.

  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?

  Single sentence with no redundant words or fluff. Front-loaded with the core action. However, extreme brevity contributes to informational gaps; efficiency is high but appropriateness of size for complexity is questionable.

  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?

  Inadequate for a 6-parameter mutation tool with no annotations and no output schema. Missing: sibling differentiation, behavioral side effects, return value description, and clarification of the optional original message reference workflow implied by the schema.

  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 has 100% description coverage, documenting all 6 parameters including the 'Additional comment' nature of body fields. Description adds no parameter semantics beyond schema, which is acceptable given high coverage, meeting the baseline.

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

  Purpose3/5

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

  States the basic action (forward email to recipient) but lacks specificity regarding scope or differentiation from siblings like send_email or send_reply. Does not clarify what distinguishes a 'forward' from a reply or new message in this context.

  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?

  Provides no guidance on when to use this tool versus send_reply or send_email. Does not explain the workflow for optional parameters (original_message_id/folder) or when the tool can be used without referencing an original email.

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

• delete_folderC
  2.8/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. While 'Delete' implies destruction, it fails to disclose whether deletion is permanent, recursive (affects subfolders/emails), or recoverable. Lacks safety-critical behavioral context expected for a destructive operation.

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

  Conciseness3/5

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

  Extremely terse at four words. While front-loaded and without wasted sentences, it is inappropriately brief for a destructive operation lacking annotations, omitting necessary warnings and behavioral constraints.

  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?

  Inadequate for a destructive tool with no annotations and no output schema. Missing crucial details: error conditions (folder not found, folder not empty), cascade behavior, and permission requirements.

  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% (folder_name is fully described in schema). Description adds no additional parameter semantics beyond what the schema provides, meeting baseline expectations for high-coverage schemas.

  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?

  States a specific verb (Delete) and resource (email folder). Distinguishes implicitly from delete_email by specifying 'folder' and from file system folders by specifying 'email', though it does not explicitly contrast with sibling tools like rename_folder or create_folder.

  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?

  Provides no guidance on when to use versus alternatives, prerequisites (e.g., must the folder be empty?), or side effects. Critical safety information regarding content handling is absent.

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

• copy_emailC
  2.9/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 full behavioral disclosure. It fails to clarify that the original email remains in the source folder (the key difference from move), whether the operation is idempotent, what the return value is (no output schema exists), or if duplicate UIDs are created.

  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 single sentence is appropriately brief and front-loaded with the action. However, extreme brevity comes at the cost of omitting crucial behavioral and contextual details needed for a mutation tool.

  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?

  For a mutation operation with 4 parameters, no annotations, and no output schema, the description is insufficient. It lacks explanation of the copy behavior, return values, and the mutual exclusivity of 'message_id' versus 'uid' parameters.

  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?

  With 100% schema description coverage, the structured documentation already explains all four parameters adequately. The description adds no parameter-specific semantics, but the baseline score of 3 is appropriate since the schema carries the load.

  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 clear verb ('Copy') and resource ('email') with destination context ('to another folder'). However, it fails to distinguish from the sibling tool 'move_email', which is critical since both involve changing folder locations but differ in whether the original is preserved.

  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 (particularly 'move_email'), nor does it mention prerequisites like requiring either 'message_id' or 'uid' as indicated by the schema's anyOf constraint.

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

• create_folderC
  2.9/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. However, it fails to mention critical behavioral traits such as whether the operation is idempotent, what happens if a folder with the same name exists, or any permission requirements.

  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 extremely concise at only four words with no filler content. However, given the lack of annotations and output schema, it may be inappropriately brief rather than optimally concise, though it efficiently communicates the core action.

  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 single-parameter tool with complete schema coverage, the description is minimally adequate. However, gaps remain regarding error handling (duplicate names), return values, and folder hierarchy behavior (nesting), which should be addressed given the absence of annotations or output schema.

  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?

  With 100% schema description coverage, the input schema fully documents the folder_name parameter. The description adds no additional parameter semantics (e.g., naming constraints, character limits), warranting the baseline score for high-coverage schemas.

  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 ('Create') and resource ('email folder'), making the purpose clear. It implicitly distinguishes from siblings like delete_folder and rename_folder through the verb choice, though it does not explicitly reference 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 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 (e.g., when to use rename_folder instead, or prerequisites like checking if a folder already exists). It simply states the action without contextual usage constraints.

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

• mark_flaggedC
  2.9/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. While 'Mark' implies a mutation, the description lacks details on idempotency (can you flag an already flagged email?), side effects, or return values.

  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 single sentence is efficient and front-loaded with the core action. However, it is minimal to the point of under-specification given the lack of annotations; additional context could be added without sacrificing clarity.

  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 tool with 100% schema coverage and simple boolean-like state change, the description is minimally adequate. However, given zero annotations and no output schema, the description should disclose behavioral traits (mutations, idempotency) to be 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?

  With 100% schema description coverage, the schema fully documents all three parameters including the default folder value and the message identifier options. The description adds no additional parameter context, meeting the baseline expectation when schema coverage is high.

  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 (mark as flagged) and clarifies the terminology with '(starred)'. However, it does not explicitly differentiate from the sibling tool 'unmark_flagged' or explain when to use this versus other marking operations.

  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?

  No guidance provided on when to use this tool versus alternatives like 'unmark_flagged', nor any mention of prerequisites (e.g., email must exist) or when to prefer 'message_id' vs 'uid'.

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

• mark_readC
  2.9/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. It implies a state-changing mutation via 'Mark' but fails to disclose idempotency, return values, error handling, side effects, or permission requirements. It adds minimal context beyond the tool name.

  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 extremely concise with zero wasted words. However, given the lack of annotations and output schema, it may be overly terse—failing to address the dual identifier system (message_id vs uid) or mutation behavior that would help an agent select and invoke the tool correctly.

  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?

  For a state-changing tool with no annotations and no output schema, the description is incomplete. It omits crucial context such as the nature of the mutation, success/failure indicators, and guidance on the mutually exclusive identifier parameters (message_id vs uid) despite the schema's anyOf logic.

  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 description contributes nothing to parameter semantics ('Mark email as read' does not explain folder, message_id, or uid). However, the input schema has 100% description coverage, establishing a baseline of 3. The description neither adds to nor detracts from the schema documentation.

  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 verb (Mark), resource (email), and target state (read/seen). However, it does not explicitly differentiate from sibling tools like 'mark_unread' or 'mark_flagged' within the text itself, relying on the tool name for distinction.

  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 (e.g., when to use 'message_id' vs 'uid', or when to prefer this over 'mark_unread'). It states only what the tool does, not when to invoke it.

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

• move_emailC
  2.9/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. While 'move' implies the email is removed from the source folder, the description does not explicitly confirm this destructive behavior, nor does it mention error conditions (e.g., target folder not existing) or permission requirements.

  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 single sentence is efficient and front-loaded with no wasted words. However, given the tool's complexity (4 parameters with conditional logic), the description borders on under-specification rather than optimal conciseness.

  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?

  Inadequate for a mutation tool with complex parameter logic (anyOf constraint) and no output schema or annotations. The description should explain the identifier choice (message_id vs uid) and confirm the destructive nature of the move operation to be 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?

  With 100% schema description coverage, the baseline score applies. The description does not add semantic clarification beyond the schema (e.g., explaining the difference between 'message_id' and 'uid' or providing examples), but it is not required to given the comprehensive schema coverage.

  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?

  States a clear verb-resource combination ('Move email to another folder') that accurately describes the operation. However, it fails to distinguish from the sibling 'copy_email' tool, which performs a superficially similar action but with different source-preservation behavior.

  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?

  Provides no guidance on when to use this tool versus 'copy_email' or other alternatives. Does not explain the logical constraint requiring either 'message_id' OR 'uid' (not both), leaving the agent to infer this from the schema's anyOf block alone.

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

• rename_folderC
  2.9/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 full burden of behavioral disclosure. It fails to specify mutation semantics (idempotency, atomicity), error handling (what if 'old_name' doesn't exist or 'new_name' is taken), or required permissions. For a state-changing 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.

  Conciseness4/5

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

  Extremely concise at four words with no redundancy. The single sentence is front-loaded with the action. However, 'appropriately sized' is debatable given the lack of behavioral context that must be inferred by the agent.

  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 simple input schema (two flat string parameters) and lack of output schema, the description covers the happy path adequately. However, for a mutation tool with zero annotations, it lacks necessary context regarding failure modes, transaction safety, and side effects.

  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% ('Current folder name' and 'New folder name'), so the baseline expectation is met. The description adds no additional parameter context (e.g., case sensitivity, character limits), but none is required given the comprehensive 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?

  States a specific verb ('Rename') and resource ('email folder'), clearly distinguishing from sibling tools like 'create_folder', 'delete_folder', and 'move_email'. However, it lacks scope constraints (e.g., whether it works on system folders or only user-created ones).

  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?

  Provides no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., folder existence checks) or exclusion criteria. The agent receives no signals about error conditions like name collisions.

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

• send_emailC
  2.9/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. It only notes that HTML and attachments are 'optional' but fails to disclose mutation side effects, success/failure indicators, rate limits, or attachment size constraints.

  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, efficient sentence that front-loads the core action. It contains no redundant or wasted words given the information it chooses to convey.

  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?

  For a 7-parameter mutation tool with no output schema and no annotations, the description is insufficient. It lacks critical context such as return values, error handling, authentication scope, or operational limits (e.g., attachment size) that an agent needs to invoke the tool correctly.

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

  Parameters3/5

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

  With 100% schema description coverage, the schema already fully documents all 7 parameters. The description adds minimal semantic value beyond confirming that HTML body and attachments are optional features, meeting the baseline expectation.

  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 the specific action ('Send an email') and mentions key capabilities ('optional HTML body and attachments'). However, it does not explicitly differentiate from sibling tools like send_forward or send_reply, leaving the distinction to be inferred from tool names alone.

  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 like send_reply or send_forward, nor does it mention prerequisites such as authentication requirements or rate limits.

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

• list_foldersB
  3/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 fails to specify whether this is a read-only operation, what data structure is returned, whether it includes system folders (Inbox, Sent), or if there are pagination limits. The word 'all' implies comprehensiveness but doesn't define scope boundaries.

  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 extremely concise at four words. While efficient and front-loaded, it may be overly terse given the absence of output schema and annotations. However, it avoids tautology and wastes no words.

  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?

  Given the lack of output schema and annotations, the description should explain what constitutes a 'folder' object in the return data (names, IDs, paths, hierarchy) and whether subfolders are flattened or nested. The current description leaves critical operational context undefined.

  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 contains zero parameters. According to the evaluation rubric, tools with no parameters receive a baseline score of 4, as there are no parameter semantics to clarify beyond what the schema already conveys (100% description coverage of empty 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 uses a specific verb ('List') and resource ('email folders') that clearly conveys the tool's function. While it distinguishes itself implicitly from email-centric siblings (copy_email, send_email) by focusing on folders rather than messages, it lacks explicit differentiation from folder manipulation tools like create_folder or rename_folder.

  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. It does not indicate whether this retrieves all folders recursively, only top-level folders, or how it relates to the get_email operation which might also access folder metadata.

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

• delete_emailB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry full behavioral disclosure. It reveals the two-step process (mark deleted + expunge), indicating IMAP-style permanent deletion. However, it omits critical safety context: irreversibility warnings, permission requirements, or error behavior when message_id/uid doesn't exist.

  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?

  Extremely efficient single sentence with parenthetical detail. Every word serves a purpose: 'Delete' (action), 'email' (resource), 'mark as deleted and expunge' (behavioral specificity). No redundancy or fluff.

  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?

  Adequate for a 3-parameter tool with complete schema documentation, but minimal for a destructive operation lacking both annotations and output schema. The description should explicitly warn about permanent data loss given the absence of structured safety hints (destructiveHint).

  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?

  Input schema has 100% description coverage (folder default, message_id as sequence number, uid as unique ID). The description adds no parameter-specific guidance, but since the schema fully documents all 3 parameters including the anyOf requirement (message_id OR uid), 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?

  States specific action (Delete) and resource (email). The parenthetical '(mark as deleted and expunge)' clarifies the technical mechanism, distinguishing it from sibling tools like move_email (relocation) and mark_read/unread (flag changes). However, it doesn't explicitly state this is permanent destruction vs. soft deletion.

  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?

  Provides no guidance on when to use this tool versus alternatives. Fails to mention that move_email should be used to move messages to a trash folder, while this tool permanently expunges them. No prerequisites or 'when-not' warnings are included despite being a destructive operation.

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

• mark_unreadB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It adds valuable behavioral context by specifying the mechanism ('remove seen flag'), revealing this is an IMAP flag operation. However, it omits safety-critical details like whether the operation is idempotent, reversible (via mark_read), or if it triggers notifications.

  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?

  Extremely concise at 6 words. Front-loaded with the action verb, zero redundancy, and the parenthetical technical detail earns its place by clarifying the underlying protocol mechanism without bloating the text.

  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?

  Adequate for a simple state-toggle tool with complete parameter documentation. The description covers the core action and mechanism. Missing minor context like relationship to mark_read or output behavior, but sufficient given the low complexity and rich input schema.

  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%, documenting folder, message_id, and uid. The description adds no parameter-specific guidance beyond the schema (e.g., no explanation of when to use message_id vs uid), earning the baseline score for high-coverage schemas.

  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?

  Clear verb ('Mark') and resource ('email') with specific state ('unread'). The parenthetical '(remove seen flag)' provides technical precision that distinguishes this from sibling flag operations like mark_flagged. However, it does not explicitly differentiate from mark_read (the inverse operation), relying on the tool name for that contrast.

  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?

  No guidance on when to use this tool versus alternatives. It does not indicate typical workflows (e.g., 'use to undo a mistaken mark_read' or 'use to remind yourself to follow up later'). The description only states what the tool does, not when to choose it.

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

• unmark_flaggedA
  3.6/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 and only discloses the basic mutation (removing a flag). It lacks critical behavioral details: idempotency (can it unmark already unmarked emails?), error handling, permission requirements, or side effects.

  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 efficient sentence with zero waste. The parenthetical '(remove starred)' adds clarifying synonymy without clutter, making it appropriately front-loaded and dense with 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 3-parameter state-toggle tool with complete schema coverage and no output schema, the description is sufficient. It could be improved by referencing the sibling 'mark_flagged' tool or noting the return behavior, but the core functionality is adequately covered.

  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 description does not mention any parameters, but the input schema has 100% description coverage, establishing a baseline of 3. The schema adequately documents the folder default and the message_id/uid alternatives without needing descriptive elaboration.

  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 ('Unmark') with clear resource ('email') and clarifies the action removes the 'starred' status. It effectively distinguishes from the sibling 'mark_flagged' tool through the contrasting verb and parenthetical clarification.

  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 through the verb 'Unmark' (suggesting use when removing a flag), but provides no explicit when-to-use guidance, prerequisites (e.g., email must be flagged), or mention of the inverse operation (mark_flagged).

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

• get_current_dateA
  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 disclosure burden but only implies read-only safety through the word 'Get'. It fails to specify return format (ISO string, timestamp, object?), timezone handling (UTC vs local), or precision (date only vs datetime).

  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?

  Extremely concise at four words. Every word is essential; no filler or redundancy. Purpose is immediately stated.

  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 zero parameters and no output schema, the description minimally suffices by stating the operation. However, it omits return value format details that would be necessary for an agent to correctly use this value in email filtering or timestamping operations.

  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?

  Zero parameters exist, establishing a baseline of 4. The description appropriately requires no parameter clarification.

  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 resource ('current date and time'), clearly distinguishing this utility from the email manipulation siblings (copy_email, delete_email, etc.).

  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?

  No explicit when-to-use guidance is provided, though usage is implied (use when current date/time is needed). Since no sibling tools provide date functionality, differentiation from alternatives is moot, but integration guidance within the email workflow is absent.

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