Server Quality Checklist

Tool Scores

• check_connectionD
  1.8/5.0
  Behavior1/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it has side effects, what the response format might be, or any error conditions. The single phrase 'Check connection' provides zero behavioral context.

  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 technically concise with only two words, this represents under-specification rather than effective brevity. The description fails to provide necessary context about what's being checked or why, making it inefficient despite its short length. Every word should earn its place, but these two words don't provide sufficient value.

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

  Completeness1/5

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

  Given the complexity of a connection-checking tool in an email-focused server with no annotations and no output schema, the description is completely inadequate. It doesn't explain what system is being checked, what constitutes a successful connection, what information is returned, or how this tool relates to the email operations performed by sibling tools.

  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 with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it doesn't attempt to describe non-existent parameters. This is appropriate for a parameterless tool.

  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 'Check connection' is a tautology that merely restates the tool name without specifying what resource or system is being checked. It doesn't distinguish this tool from its siblings, which all operate on emails. The description fails to clarify whether this checks database connectivity, API status, or email server availability.

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

  Usage Guidelines1/5

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

  The description provides absolutely no guidance about when to use this tool versus alternatives. Given the sibling tools all handle email operations, there's no indication whether this should be used before other operations, as a health check, or in what context. No prerequisites, alternatives, or exclusions are mentioned.

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

• delete_emailC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It states the tool deletes an email permanently, which implies destructive behavior, but lacks details on permissions needed, irreversibility, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

  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, clearly front-loaded with the core action. It earns its place by specifying permanence, which is critical for tool selection.

  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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., consequences, auth needs), usage guidelines relative to siblings, and details on return values, leaving significant gaps for agent 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?

  Schema description coverage is 100%, so the schema documents both parameters (email_id and folder). The description adds no additional meaning beyond implying email_id is required for deletion, matching the baseline when schema does the heavy lifting.

  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 ('Delete') and resource ('email'), specifying it's a permanent deletion. It distinguishes from siblings like 'move_email_to_trash' by emphasizing permanence, though it doesn't explicitly name alternatives.

  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 is provided on when to use this tool versus alternatives like 'move_email_to_trash' or 'batch_delete_emails'. The description implies it's for permanent deletion but doesn't specify contexts or prerequisites for use.

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

• get_email_detailC
  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 states the tool 'gets' content, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data or raw content, or handles errors. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is appropriately sized and front-loaded, with every word contributing to understanding the core function.

  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 complexity of email operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed content' includes (e.g., headers, body, attachments) or the return format, which is critical for an agent to use the tool effectively. The description should compensate for these gaps but doesn't.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters (email_id and folder with default 'INBOX'). The description adds no additional meaning beyond implying that email_id identifies the specific email, which is already clear from the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 'get' and the resource 'detailed content of a specific email', which distinguishes it from siblings like list_emails (which lists multiple emails) or get_unread_count (which provides counts). However, it doesn't explicitly differentiate from tools like mark_email_read that also operate on specific emails, keeping it from a perfect score.

  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. For example, it doesn't clarify if this should be used after list_emails to get details for a specific email ID, or if there are prerequisites like needing the email_id from another operation. No exclusions or alternatives are mentioned.

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

• list_emailsC
  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 full burden for behavioral disclosure. 'List emails from inbox' implies a read-only operation, but doesn't specify whether this requires authentication, what format the results come in (IDs, summaries, or full emails), whether it supports pagination beyond the limit parameter, or any rate limits. The description is minimal and leaves critical behavioral aspects unspecified.

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

  Conciseness5/5

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

  The description is extremely concise - just four words that directly state the tool's function. There's zero wasted language, and it's perfectly front-loaded with the essential information. Every word earns its place in this minimal but complete statement of purpose.

  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 tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (email IDs, subjects, snippets, or full emails), doesn't mention authentication requirements, and provides no context about the email system being accessed. Given the complexity of email systems and the lack of structured documentation, the description should do much more.

  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 documented in the schema. The description adds no additional parameter information beyond what's in the schema - it doesn't explain parameter interactions, default behaviors, or provide usage examples. This meets the baseline for high schema coverage but doesn't enhance understanding.

  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 ('list') and resource ('emails from inbox'), making the purpose immediately understandable. It distinguishes itself from siblings like get_email_detail (which retrieves specific email content) and get_unread_count (which only counts). However, it doesn't explicitly differentiate from batch operations or specify that it retrieves metadata rather than full content.

  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 doesn't mention when to choose list_emails over get_email_detail for viewing content, or when to use it versus batch operations for multiple emails. There's no context about prerequisites, limitations, or typical use cases.

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

• mark_email_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 states the action ('mark as read') but doesn't explain what this entails (e.g., does it update server status, require specific permissions, have side effects like notifications, or return confirmation?). For a mutation tool without annotations, this is a significant gap in transparency.

  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, direct sentence ('Mark an email as read') with zero wasted words. It is front-loaded and efficiently communicates the core purpose without unnecessary elaboration, making it easy to parse quickly.

  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 tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, error handling), return values, or how it differs from siblings like 'batch_mark_read'. For a tool that modifies state, this minimal description leaves critical gaps for an agent to use it 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%, with clear descriptions for both parameters ('email_id' and 'folder'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate or enhance understanding.

  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 'Mark an email as read' clearly states the action (mark as read) and resource (an email), making the purpose immediately understandable. It distinguishes from siblings like 'delete_email' or 'move_email_to_trash' by focusing on read status modification. However, it doesn't specify if this applies to a single email versus batches (contrasted with 'batch_mark_read'), leaving some ambiguity.

  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 doesn't mention prerequisites (e.g., needing an email ID), exclusions (e.g., not for unread emails only), or comparisons to siblings like 'batch_mark_read' for multiple emails. This lack of context leaves the agent to infer usage from the tool name alone.

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

• move_email_to_trashC
  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 states the action ('Move') but doesn't clarify if this is reversible, what happens if the email is already in trash, or any rate limits or authentication requirements. This leaves significant gaps in understanding the tool's behavior beyond the basic operation.

  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 directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly, earning the highest score for 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?

  Given the complexity of a mutation tool (moving emails) with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like reversibility, error conditions, or response format, leaving the agent with incomplete context for safe and effective use.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents all parameters (email_id, folder, trash_folder) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or default behaviors, resulting in a baseline score of 3.

  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 ('Move') and resource ('an email to trash folder'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'batch_move_to_trash' or 'delete_email', which perform similar operations, so it doesn't reach the highest score for sibling 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 like 'batch_move_to_trash' for multiple emails or 'delete_email' for permanent deletion. It lacks context about prerequisites, such as whether the email must be accessible or if specific permissions are needed, leaving the agent with minimal usage direction.

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

• get_unread_countB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it works - whether it requires authentication, has rate limits, returns a simple integer or structured data, or any error conditions. For a tool with zero annotation coverage, this is a significant gap.

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

  Conciseness5/5

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

  The description is perfectly concise - a single sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core functionality and doesn't include unnecessary information.

  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 annotations and output schema, the description is insufficiently complete. It doesn't explain what format the count is returned in (integer, object with metadata), whether it's real-time or cached, or any behavioral aspects. For a tool that presumably interacts with email systems, more context is needed.

  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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, which is correct. Baseline for 0 parameters is 4.

  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 ('get count') and resource ('unread emails'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'list_emails' or 'get_email_detail', but it's specific enough to understand what it does.

  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 'list_emails' (which might also provide count information) or other email-related tools. There's no mention of prerequisites, context, or exclusions.

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

• batch_delete_emailsB
  3.2/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. It states 'permanently delete,' which implies an irreversible, destructive mutation, but does not disclose critical behavioral traits like required permissions, error handling for invalid IDs, rate limits, or confirmation prompts. The description is minimal and misses key operational details.

  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. It is front-loaded with the core action and resource, making it immediately clear without unnecessary elaboration. Every word earns its place.

  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 complexity of a batch deletion tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., irreversible nature, error handling), usage context compared to siblings, and expected outcomes. For a destructive operation, this is a significant gap.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters ('email_ids' and 'folder') fully. The description adds no additional meaning beyond what the schema provides, such as format details for IDs or folder implications. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 specific action ('permanently delete'), resource ('multiple emails'), and scope ('in batch'), distinguishing it from siblings like 'delete_email' (singular) and 'batch_move_to_trash' (non-permanent). It uses precise verbs and specifies the batch nature of the 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?

  The description provides no guidance on when to use this tool versus alternatives like 'batch_move_to_trash' (for reversible deletion) or 'delete_email' (for single emails). It lacks context about prerequisites, such as whether emails must be in a specific state or folder, or any exclusions for use.

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

• batch_mark_readB
  3.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 the full burden of behavioral disclosure. It states the action but doesn't mention whether this requires specific permissions, if changes are reversible, potential rate limits, or error handling for invalid IDs. For a mutation tool with zero annotation coverage, this leaves significant gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.

  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 no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error responses, or return values, leaving the agent with insufficient context for safe and effective invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional parameter semantics beyond implying batch processing for 'email_ids'. It doesn't clarify folder usage or parameter interactions beyond what the schema provides.

  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 read') and resource ('multiple emails'), with 'in batch' indicating a bulk operation. It distinguishes from the singular 'mark_email_read' sibling tool by specifying batch capability, though it doesn't explicitly mention the folder parameter scope.

  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 for bulk marking emails as read, but provides no explicit guidance on when to use this versus the singular 'mark_email_read' tool, nor does it mention prerequisites like authentication or folder access. It lacks clear alternatives or exclusions.

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

• batch_move_to_trashB
  3.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 the full burden of behavioral disclosure. It states the action but does not cover critical aspects like permissions required, whether the move is reversible, error handling for invalid IDs, or rate limits. This leaves significant gaps for a mutation tool.

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

  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 purpose without unnecessary words. It is appropriately sized for the tool's complexity, with every part contributing directly to understanding the action.

  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 tool's complexity as a batch mutation with no annotations and no output schema, the description is incomplete. It fails to address behavioral traits like side effects, response format, or error scenarios, which are essential for safe and effective use by an agent.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents all parameters (email_ids, folder, trash_folder) with descriptions. The description adds no additional meaning beyond what the schema provides, such as usage examples or constraints, meeting the baseline for high coverage.

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

  Purpose5/5

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

  The description clearly states the specific action ('Move multiple emails to trash folder') and resource ('emails'), distinguishing it from siblings like 'delete_email' or 'move_email_to_trash' by emphasizing batch processing. It directly answers what the tool does without ambiguity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, such as 'batch_delete_emails' or 'move_email_to_trash', nor does it mention prerequisites or exclusions. It lacks context for decision-making among sibling tools.

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