Server Quality Checklist

Tool Scores

• connect-gmailC
  2.2/5.0
  Behavior1/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. 'Connect to Gmail' reveals nothing about what the operation actually does: whether it authenticates, establishes a session, returns connection status, requires specific permissions, has side effects, or what happens on failure. For a zero-parameter tool with no annotation coverage, this complete lack of behavioral information is inadequate.

  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 concise at just three words, but this brevity comes at the cost of meaningful information. While technically 'front-loaded' (the entire description is the first and only phrase), it fails to earn its place by providing insufficient guidance. The structure is minimal but not effectively communicative 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?

  Given zero parameters and no annotations or output schema, the description should provide complete operational context but fails to do so. 'Connect to Gmail' doesn't explain what the tool returns, what state changes occur, or how it integrates with the 15 sibling Gmail tools. For a connection/authentication tool in a rich ecosystem, this minimal description leaves critical gaps about the tool's role and behavior.

  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 score is 4. The description doesn't need to compensate for any parameter documentation gaps since there are no parameters to document. While it doesn't add parameter-specific information (because none exist), it doesn't detract from the complete schema coverage either.

  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 'Connect to Gmail' is essentially a tautology that restates the tool name 'connect-gmail' without adding meaningful specificity. It doesn't explain what 'connect' means operationally (e.g., authenticate, establish session, verify credentials) or what resource is being connected to beyond the obvious Gmail service. While it mentions the target service, it lacks a clear verb+resource combination that distinguishes it from sibling tools like 'check-gmail-connection'.

  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 explain prerequisites (e.g., whether authentication is required), when this should be called relative to other operations, or how it differs from 'check-gmail-connection'. With multiple sibling tools for Gmail operations, the absence of any usage context leaves the agent guessing about appropriate invocation scenarios.

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

• get-gmail-settingsC
  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 the full burden of behavioral disclosure but only states the action ('Get') without detailing traits like read-only status, authentication needs, rate limits, or response format. It lacks critical context for safe and effective use.

  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 concise with a single sentence, but it's under-specified rather than efficiently informative. It lacks front-loaded details that would help an agent, making it more of a placeholder than a well-structured explanation.

  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 settings retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what settings are returned, potential errors, or behavioral aspects, leaving significant gaps for the agent to infer.

  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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here, earning a baseline score above 3 due to the absence of parameters.

  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 'Get Gmail settings' is a tautology that essentially restates the tool name 'get-gmail-settings' without adding meaningful specificity. It doesn't clarify what specific settings are retrieved or how this differs from other Gmail-related tools like 'get-email' or 'get-labels', which would be needed for sibling differentiation.

  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 no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, such as whether it requires authentication or if it's for retrieving global versus user-specific settings, leaving the agent with no usage direction.

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

• send-emailC
  2.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 only states the action 'send an email'. It doesn't disclose critical traits like whether this requires authentication, if it's a mutation (likely yes), rate limits, error conditions, or what happens after sending (e.g., confirmation). The description is minimal and fails to compensate for the lack of 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 extremely concise with just three words, 'Send an email', which is front-loaded and wastes no space. While it may be under-specified, it earns a high score for brevity and lack of redundancy.

  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 an email-sending tool with no annotations and no output schema, the description is incomplete. It doesn't address authentication needs, success/failure responses, or how it differs from sibling tools. For a mutation tool with potential side effects, more context is needed to guide the agent effectively.

  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%, with clear descriptions for 'to', 'subject', and 'body' parameters. The description adds no additional meaning beyond what the schema provides, but since the schema is well-documented, the baseline score of 3 is appropriate. No parameter details are mentioned in the description itself.

  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 'Send an email' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'send-draft' or 'reply-to-email', nor does it clarify what type of email is being sent (e.g., new email vs. forwarding). The verb 'send' is clear but lacks context about the resource scope.

  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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'send-email' over 'send-draft', 'reply-to-email', or 'forward-email', nor does it specify prerequisites like authentication or context requirements. This leaves the agent with no usage context.

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

• get-emailsC
  2.6/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 action ('Get emails') but doesn't cover critical traits like whether this is a read-only operation, if it requires authentication, rate limits, pagination, or what the return format looks like. This is a significant gap for a tool with no 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.

  Conciseness4/5

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

  The description is extremely concise ('Get emails from inbox')—just four words. It's front-loaded and wastes no words, though it might be overly terse given the lack of behavioral context. Every word earns its place, but it could benefit from slightly more detail.

  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 (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'inbox' refers to, the return format, or how results are ordered. With no annotations to fill gaps, the description should provide more context to help the agent use the tool effectively.

  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%, with clear documentation for all three parameters (maxResults, query, labelIds). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage.

  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 'Get emails from inbox' clearly states the verb ('Get') and resource ('emails from inbox'), making the purpose understandable. However, it's vague about scope (e.g., which inbox, all emails vs. recent) and doesn't distinguish from siblings like 'get-email' (singular) or 'search-emails', which could cause confusion.

  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 'search-emails' or 'get-threads'. It lacks context about use cases, prerequisites, or exclusions, leaving 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.

• reply-to-emailC
  2.6/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 but only states the action without disclosing behavioral traits. It doesn't mention if this is a mutation (likely yes), permission requirements, rate limits, or what happens upon execution (e.g., sends immediately vs. creates draft). This leaves significant gaps for a tool that modifies data.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it's overly concise, bordering on under-specified for a mutation tool, which slightly reduces its effectiveness.

  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 an email reply tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error conditions, or return values, making it inadequate for safe and effective use by an AI 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?

  Schema description coverage is 100%, so the schema already documents both parameters (emailId and message). The description adds no meaning beyond what the schema provides, such as format details or usage examples. Baseline 3 is appropriate as the schema handles parameter documentation.

  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 'Reply to an existing email' clearly states the action (reply) and resource (email), but it's vague about scope and doesn't differentiate from siblings like 'forward-email' or 'send-email'. It lacks specificity about what 'reply' entails (e.g., replying to sender vs. all recipients).

  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 'forward-email' or 'send-email', nor does it mention prerequisites (e.g., needing an existing email ID). The description implies usage but offers no explicit context or exclusions.

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

• get-threadsC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get email threads' implies a read-only operation but doesn't specify whether it requires authentication, how it handles pagination, what the return format is, or any rate limits. For a tool with no annotation coverage, this leaves critical behavioral traits undocumented.

  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 at just three words ('Get email threads'), with no wasted words or unnecessary elaboration. It's front-loaded and efficiently communicates the core function, making it easy to parse quickly. This is an example of optimal brevity for a simple 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?

  Given the complexity of email thread retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'threads' entail (e.g., grouped emails), how results are returned, or any authentication requirements. For a tool with rich sibling tools and no structured support, more context is needed to guide 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 input schema has 100% description coverage, with clear documentation for both parameters ('maxResults' and 'query'). The description adds no parameter-specific information beyond what's in the schema, so it doesn't enhance semantic understanding. According to the rules, baseline is 3 when schema coverage is high (>80%) and no param info is added.

  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 'Get email threads' clearly states the verb ('Get') and resource ('email threads'), making the basic purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'get-emails' or 'search-emails', leaving ambiguity about when to use each. The description is functional but lacks specificity about scope or differentiation.

  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 'get-emails' or 'search-emails'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone. This lack of explicit guidance reduces effectiveness in tool selection.

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

• create-draftC
  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. 'Create an email draft' implies a write operation but doesn't specify whether it requires authentication, what happens on failure, if drafts are saved immediately, or any rate limits. This leaves significant gaps for an agent to understand the tool's 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 with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.

  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 insufficient. It doesn't explain what happens after creation (e.g., where the draft is stored, if it returns a draft ID), authentication requirements, or error conditions. Given the complexity of email operations, more context is needed.

  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 all three parameters ('to', 'subject', 'body') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline for high 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?

  The description 'Create an email draft' clearly states the verb ('Create') and resource ('an email draft'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'send-email' or 'send-draft', which would require more specificity about what distinguishes draft creation from sending.

  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-email' or 'send-draft'. There's no mention of prerequisites (e.g., needing a connected Gmail account) or typical use cases (e.g., saving an email for later editing).

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

• create-labelC
  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 but only states the basic action. It doesn't mention whether this requires specific permissions, what happens on duplicate label names, whether labels are user-specific or global, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.

  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 states the core purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential 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?

  For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens on success (e.g., returns label ID), error conditions, authentication requirements, or how it fits within the broader Gmail context. The agent would have significant gaps in understanding how to use this tool effectively.

  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 the basic purpose. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with any extra context about parameter usage.

  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 'Create' and the resource 'new Gmail label', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-labels' or explain what distinguishes label creation from other Gmail operations, preventing 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. It doesn't mention prerequisites (like needing authentication), when label creation is appropriate versus using existing labels, or how it relates to sibling tools like 'get-labels' for checking existing labels first.

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

• forward-emailC
  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. It mentions the action ('forward') which implies a mutation, but doesn't address permissions, side effects (e.g., whether the original email is modified), rate limits, or error conditions. 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 with no wasted words. 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 lacks details on behavioral traits (e.g., what happens after forwarding), error handling, or return values, leaving the agent with insufficient context for reliable 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?

  Schema description coverage is 100%, so the input schema fully documents all three parameters. The description adds no additional meaning beyond implying 'emailId' and 'to' are required (matching schema) and that 'message' is optional additional content. This meets the baseline for high 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?

  The description clearly states the action ('forward') and resource ('an email'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'reply-to-email' or 'send-email' beyond the basic verb, which prevents 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 like 'reply-to-email' or 'send-email', nor does it mention prerequisites such as needing an existing email ID. It simply states what the tool does without context for selection.

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

• get-emailC
  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 tool retrieves an email but doesn't describe what information is returned (e.g., headers, body, attachments), error handling (e.g., for invalid IDs), or performance aspects (e.g., rate limits). This is inadequate for a read operation 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 wasted words. It is front-loaded with the core purpose ('Get a specific email by ID'), making it immediately scannable and easy to parse. This is an excellent example of 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., email object structure), error conditions, or dependencies (e.g., how to obtain an email ID). For a tool with no structured output documentation, this leaves significant gaps for an agent to use it effectively.

  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%, with the single parameter 'emailId' clearly documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format examples or source of the ID). Given the high coverage, the baseline score of 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.

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('a specific email by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get-emails' (plural) by specifying retrieval of a single email. However, it doesn't explicitly mention what 'get' entails (e.g., fetching metadata, content, or both), which prevents 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 like 'get-emails' or 'search-emails'. It doesn't mention prerequisites (e.g., needing an email ID from another operation) or exclusions (e.g., not for bulk retrieval). This leaves the agent with minimal context for tool selection.

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

• mark-as-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 full burden for behavioral disclosure. While 'mark as read' implies a mutation operation, the description doesn't specify whether this requires specific permissions, if changes are reversible, what happens if email IDs are invalid, or any rate limits. It provides minimal behavioral context beyond the basic action.

  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 with just three words that directly convey the core functionality. Every word earns its place, and there's no unnecessary information or redundancy.

  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 inadequate. It doesn't explain what happens after marking emails as read, whether the operation is synchronous, what errors might occur, or any side effects. The minimal description leaves too many behavioral questions unanswered.

  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 the single parameter 'emailIds' clearly documented in the schema. The description doesn't add any parameter information beyond what's already in the schema, so it meets the baseline score 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 read') and the resource ('emails'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling 'mark-as-unread' tool, which performs the opposite operation on the same resource type.

  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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing connected Gmail), when not to use it, or how it differs from similar tools like 'mark-as-unread'.

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

• mark-as-unreadC
  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. 'Mark emails as unread' implies a mutation operation, but it fails to describe key traits like whether it requires specific permissions, if changes are reversible, potential rate limits, or what happens on success/failure. This leaves significant gaps for an agent to understand the tool's 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, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning full marks for brevity and clarity.

  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 incomplete for a mutation tool. It does not address behavioral aspects like error handling, return values, or operational constraints, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.

  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 the parameter 'emailIds' fully documented in the schema as 'Array of email IDs to mark as unread'. The description does not add any additional meaning or context beyond this, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.

  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 emails as unread' clearly states the verb ('mark') and resource ('emails') with a specific action ('as unread'), making the purpose immediately understandable. However, it does not explicitly differentiate from the sibling tool 'mark-as-read', which is a minor gap in 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 'mark-as-read' or other email management tools in the sibling list. It lacks context about prerequisites, such as needing valid email IDs or when marking as unread is appropriate (e.g., after reading or for follow-up).

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

• move-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 full burden for behavioral disclosure. It states the action but doesn't mention whether this is reversible, if it requires specific permissions, what happens to emails in trash (e.g., auto-deletion), or error handling. 'Move to trash' implies a soft delete, but this isn't explicitly clarified.

  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 at three words with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

  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 insufficient. It doesn't explain what happens after moving to trash, whether the operation is atomic, what errors might occur, or what the return value might be. The context signals indicate a simple tool, but more behavioral context is needed.

  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 the parameter 'emailIds' clearly documented in the schema as 'Array of email IDs to move to trash'. The description doesn't add any additional meaning beyond what the schema already provides, so it meets the baseline for high 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?

  The description 'Move emails to trash' clearly states the action (move) and target resource (emails) with a specific destination (trash). It distinguishes from siblings like 'delete' or 'archive' by specifying trash, but doesn't explicitly differentiate from other email management tools beyond the obvious verb.

  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 deleting permanently or archiving. The description only states what it does, not when it's appropriate or what prerequisites might exist (e.g., needing valid email IDs).

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

• search-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 but offers minimal behavioral insight. It mentions 'Gmail search syntax' which hints at query capabilities, but doesn't disclose whether this is read-only, what permissions are needed, how results are returned (e.g., pagination, format), rate limits, or error conditions. For a search tool with zero annotation coverage, this is inadequate.

  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 wasted words. It's front-loaded with the core purpose ('Search emails') and adds just enough context ('using Gmail search syntax'). Every word earns its place, making it easy for an agent 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 moderate complexity (search with parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., list of emails, metadata), how to handle results, or any behavioral traits like authentication needs. For a search tool in a Gmail context with many siblings, more completeness is needed.

  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 fully documents both parameters (query and maxResults). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain query syntax beyond mentioning 'Gmail search syntax' (which the schema already covers with examples), nor does it clarify maxResults defaults or constraints. Baseline 3 is appropriate when schema does all the work.

  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 ('search') and resource ('emails'), and specifies the search method ('using Gmail search syntax'). It distinguishes from siblings like 'get-emails' by emphasizing search functionality rather than retrieval. However, it doesn't explicitly differentiate from all potential search-related siblings.

  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 'get-emails' or 'search' functions in other tools. It doesn't mention prerequisites (e.g., needing authentication via connect-gmail) or exclusions. The agent must infer usage from the name and context alone.

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

• send-draftC
  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. 'Send a draft email' implies a write/mutation operation that will transmit an email, but it doesn't disclose whether this is irreversible, what permissions are required, what happens to the draft after sending, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate.

  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 at three words. It's front-loaded with the essential action and resource, with zero wasted words. Every element earns its place in this minimal description.

  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 this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after sending (success/failure indicators, what the draft becomes), doesn't mention error conditions, and provides minimal behavioral context. The agent would need to guess about important operational aspects.

  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% (the single parameter 'draftId' is fully documented in the schema), so the baseline score is 3. The description adds no additional parameter information beyond what's already in the schema, which is acceptable 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?

  The description 'Send a draft email' clearly states the verb ('send') and resource ('draft email'), making the tool's purpose immediately understandable. However, it doesn't distinguish this tool from the sibling 'send-email' tool, which appears to be a different sending mechanism. A perfect score would require explicit differentiation from that alternative.

  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. There's no mention of prerequisites (like needing a draft created first), when to use 'send-draft' versus 'send-email', or any contextual constraints. The agent must 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.

• check-gmail-connectionB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Check') but doesn't reveal any behavioral traits such as whether it requires authentication, what the output format might be (e.g., boolean, detailed status), or if it has side effects (e.g., logging, rate limits). This leaves significant gaps for an agent to understand how to invoke it effectively.

  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—'Check Gmail connection status' is front-loaded and directly conveys the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action and target.

  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 (a diagnostic tool with no parameters) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what 'connection status' means or what the tool returns, leaving the agent uncertain about the outcome. For a tool that likely provides critical system information, more context is needed to be fully helpful.

  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, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any schema gaps.

  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 ('Check') and resource ('Gmail connection status'), making the purpose immediately understandable. It distinguishes this from siblings like 'connect-gmail' (which likely establishes a connection) and 'get-gmail-settings' (which retrieves configuration). However, it doesn't specify what 'connection status' entails (e.g., authentication validity, API availability), 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?

  No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used before attempting other Gmail operations, or if it's redundant when 'connect-gmail' is available. The description implies a diagnostic use but lacks explicit context or exclusions.

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

• get-labelsB
  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 full burden for behavioral disclosure. 'Get all Gmail labels' implies a read-only operation but doesn't specify whether it requires authentication, returns paginated results, includes system vs. user labels, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

  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 ('Get all Gmail labels') that front-loads the core purpose without unnecessary words. Every word earns its place: 'Get' specifies the action, 'all' clarifies scope, 'Gmail' defines the domain, and 'labels' identifies the resource. No structural issues or redundancy exist.

  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 tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context about authentication needs, return format, or error handling. For a read operation in a Gmail context, more guidance would be helpful, but the description meets basic requirements for such a straightforward tool.

  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 has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. This meets the baseline for tools with no parameters, as there's nothing to compensate for.

  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 'Get all Gmail labels' clearly states the verb ('Get') and resource ('Gmail labels'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'create-label' or 'get-gmail-settings', but the specificity of 'labels' provides inherent distinction. The description avoids tautology with the tool name 'get-labels' by adding the resource domain ('Gmail').

  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 Gmail connection), compare to similar tools like 'get-gmail-settings' or 'create-label', or indicate use cases (e.g., for listing available labels before filtering emails). The agent must infer usage from the tool name and context alone.

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