Server Quality Checklist

Tool Scores

• list_unreadB
  3.3/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. It successfully documents the return structure (email object fields) and parameter constraints (1-100 range). However, lacks safety context (auth requirements, rate limits) and behavior on empty inbox.

  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?

  Uses docstring format with Args/Returns sections. First sentence is strong and front-loaded. Returns section may be redundant if rich output schema exists, but structure is logical and information density is high with minimal waste.

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

  Completeness3/5

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

  Adequate for a single-parameter list operation. Describes the parameter fully and outlines return fields. Lacks completeness on behavioral edge cases and sibling differentiation, which would elevate it for an email tool with multiple query options.

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

  Parameters4/5

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

  Schema coverage is 0% (max_results lacks description), but description fully compensates by documenting the parameter semantics, valid range (1-100), and default value (20).

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

  Purpose4/5

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

  States specific verb (List) + resource (unread emails) + scope (from inbox). Clearly implies read-only operation distinct from mutation siblings like 'archive' and 'mark_as_read', 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?

  Provides no explicit guidance on when to use this versus the 'search' sibling, which could also retrieve unread emails. No preconditions or filtering guidance provided.

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

• get_labelsB
  3.4/5.0
  Behavior3/5

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

  Lacks annotations, so the description carries full disclosure burden. It clarifies scope ('all Gmail labels', 'authenticated user') but omits safety confirmation (read-only nature), rate limits, or whether system labels are included. The return value description is redundant since output schema exists.

  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?

  Front-loaded action sentence followed by return description. Efficient structure with minimal waste, though the Returns sentence adds limited value given the existence of an output schema.

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

  Completeness4/5

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

  Adequate for a simple read operation with no parameters and existing output schema. Covers the essential operation scope, though additional context on label types (system vs. user) would improve completeness given zero annotation coverage.

  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?

  Input schema contains zero parameters. Per rubric, baseline score is 4 for zero-parameter tools. The description implicitly confirms no filtering is possible ('all Gmail labels'), which aligns with the empty schema.

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

  Purpose4/5

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

  Provides specific verb (Get), resource (Gmail labels), and scope (all labels for authenticated user). However, it does not explicitly differentiate from sibling tools like 'search' or 'list_unread' that might also interact with labels in different contexts.

  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?

  Offers no guidance on when to invoke this tool versus siblings like 'search' or 'list_unread', nor does it mention prerequisites such as requiring OAuth scopes or when label data is needed for subsequent operations.

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

• archiveA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the mechanism (label removal) and return structure (archived_count, failed_count), but omits safety/reversibility details, rate limits, or partial failure behavior beyond the return keys.

  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?

  Docstring-style Args/Returns format is slightly redundant with structured schema fields, but efficient given the lack of schema descriptions. No wasted prose.

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

  Completeness4/5

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

  For a single-parameter mutation tool, the description adequately covers the parameter, operation semantics, and return structure. Missing only edge-case handling details.

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

  Parameters4/5

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

  Schema coverage is 0% (no property descriptions), but the Args section compensates by documenting message_ids as 'List of message IDs to archive,' clarifying the expected input format.

  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 defines 'archive' concretely as 'removing INBOX and UNREAD labels,' avoiding tautology. It distinguishes from sibling mark_as_read by specifying both labels are removed (inbox removal is the key differentiator).

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

  Usage Guidelines2/5

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

  No guidance on when to choose this over mark_as_read (which likely only removes UNREAD) or delete. No mention of typical use cases like 'inbox zero' workflows or that archived emails remain searchable via search.

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

• searchA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It states the return type ('List of email objects'), but omits critical behavioral traits like read-only status (implicit but unconfirmed), rate limits, or result sorting order.

  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 Args/Returns structure is clear and scannable. While embedding parameter documentation in the description text is redundant when schemas exist, it is necessary here given the schema lacks descriptions. No extraneous content.

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

  Completeness3/5

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

  Adequate for a 2-parameter search tool with output schema present. Covers inputs and basic return structure, but gaps remain regarding safety profile (read-only assurance) and differentiation from the specialized 'list_unread' sibling.

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

  Parameters5/5

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

  Excellent compensation for 0% schema coverage. The Args section fully documents both parameters: 'query' includes three concrete syntax examples, and 'max_results' specifies the valid range (1-100) and default value (20) absent from the schema.

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

  Purpose4/5

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

  The description clearly identifies the action (search), resource (emails), and specific mechanism (Gmail query syntax). Examples like 'is:unread' and 'subject:invoice' implicitly distinguish it from sibling 'list_unread', though it could explicitly mention when to prefer the dedicated unread tool.

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

  Usage Guidelines3/5

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

  The description provides rich query syntax examples that implicitly guide usage, but lacks explicit guidance on when to use this versus siblings like 'list_unread' or prerequisites like authentication requirements.

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

• mark_as_readA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It partially satisfies this by documenting the return structure (marked_count, failed_count, details) in the Returns section, revealing idempotency hints (failed_count suggests partial success handling). However, it omits mutation semantics (permissions required, thread vs individual message behavior) that would be critical for a write 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?

  Uses a clean docstring structure with Args and Returns sections. Every sentence earns its place: the first line establishes the core operation and sibling distinction, Args documents the single parameter, and Returns documents the output structure. No redundancy or boilerplate.

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

  Completeness4/5

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

  For a single-parameter tool with zero schema coverage, the description adequately fills gaps by documenting the parameter (Args) and return values (Returns). Given the output schema exists (per context signals), the Returns section may be partially redundant, but still provides semantic field descriptions. Completeness is appropriate for the tool's simplicity.

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

  Parameters4/5

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

  Schema description coverage is 0%, requiring the description to compensate. The Args section successfully defines 'message_ids' as 'List of message IDs to mark as read', adding essential semantic context (the IDs represent messages) and purpose (to mark as read) that the bare JSON schema lacks. It loses a point for not specifying ID format or constraints.

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

  Purpose5/5

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

  The opening line 'Mark emails as read without archiving' provides a specific verb (Mark), resource (emails), and target state (as read). Crucially, it explicitly distinguishes itself from the 'archive' sibling tool by stating the negative constraint 'without archiving', preventing confusion between the two mutation operations.

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

  Usage Guidelines4/5

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

  The phrase 'without archiving' implicitly provides usage guidance by contrasting with the sibling 'archive' tool, indicating when to use this (when you want to keep the email in the inbox but mark it read). While it lacks exhaustive when-to-use logic for all siblings (like search vs mark), it successfully handles the most critical adjacent alternative.

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