Server Quality Checklist

Tool Scores

• gmail_read_emailA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears the full burden. It discloses the return contents but does not mention side effects, error handling, or permissions. For a read operation, it is adequate but not exhaustive.

  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 two sentences that front-load the core functionality and return value. No unnecessary words.

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

  Completeness4/5

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

  Given a single parameter, no annotations, and an output schema, the description explains the return structure. It lacks details on potential errors or limitations but covers the essential information for a simple read tool.

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

  Parameters3/5

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

  Only one parameter (message_id) exists, and schema description coverage is 0%. The description adds context that the id comes from gmail_search, but does not specify format or constraints, leaving room for ambiguity.

  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 tool reads a full email by its id, specifying what is returned (headers, body, attachment names). It also mentions the id comes from gmail_search, distinguishing it from sibling tools.

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

  Usage Guidelines4/5

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

  The description implies using gmail_search first to obtain the message_id, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternative tools.

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

• drive_read_fileA
  4.2/5.0
  Behavior3/5

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

  Discloses truncation behavior and supported file formats. No annotations exist, so description carries the burden. Lacks details on permissions, failure modes, or read-only nature.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with purpose. Every sentence provides essential info with no redundancy.

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

  Completeness4/5

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

  Given output schema exists, description doesn't need return values. Covers file types, truncation, and ID origin. Could mention plain text output or CSV for Sheets, but it's still effective.

  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 has 0% description coverage. Description adds meaning: file_id is 'from drive_search', max_chars default is 20000 and adjustable. Both parameters are explained beyond the schema.

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

  Purpose5/5

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

  Clear verb+resource: 'Read the text content of a Drive file by its id'. Explicitly distinguishes from siblings like drive_search (finds files) and gmail tools.

  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?

  Tells when to use: 'Handles Google Docs, Sheets and Slides ... PDF, Word, Excel, PowerPoint'. Provides guidance on max_chars for truncation. Could be more explicit about when not to use, but sibling context clarifies.

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

• drive_list_shared_drivesA
  4.3/5.0
  Behavior3/5

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

  Without annotations, the description carries full transparency burden. It correctly implies a read-only listing operation, but it does not disclose potential pagination, rate limits, or permission requirements. The description is minimal but not misleading.

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

  Conciseness5/5

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

  Two sentences with no wasted words. The primary action is front-loaded, and the second sentence adds valuable usage context. Every sentence earns its place.

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

  Completeness5/5

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

  For a simple parameterless listing tool with an output schema, the description is complete. It explains the purpose and suggests when to use it, while the output schema presumably covers return value 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?

  There are no parameters, so the description adds value by specifying output fields (id and name). With 100% schema coverage and zero params, the baseline is 4, and the description meets expectations.

  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 it lists shared drives with id and name, and the verb 'list' precisely indicates the action. It distinguishes from sibling tools like drive_read_file and drive_search, which serve different purposes.

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

  Usage Guidelines4/5

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

  The description suggests using this tool before searching to discover project files, providing clear context. It does not explicitly mention when not to use it or alternative tools, but the guidance is sufficient for the tool's simplicity.

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

• gmail_searchA
  4.3/5.0
  Behavior4/5

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

  No annotations present, so description covers all behavioral traits: returns specific fields (id, from, subject, date, snippet), date range meanings (after=on/after, before=before day), and default behavior with no filters. Mentions max_results indirectly via default, but does not disclose rate limits or pagination.

  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?

  Four sentences, front-loaded with purpose, followed by filtering details, date format, and mention of sibling tool. No redundant or irrelevant content.

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

  Completeness5/5

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

  Despite no annotations and many parameters, the description sufficiently explains search behavior, input combinations, return fields, and link to gmail_read_email. Output schema exists, so return format details are covered.

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

  Parameters3/5

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

  Schema has 7 parameters with 0% description coverage. Description covers keyword, sender, subject, after, before (5/7) but omits unread_only and max_results. While it gives context for most parameters, two are left undocumented, requiring compensation that is not fully provided.

  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?

  Description clearly states the tool searches Gmail and returns a compact list. It identifies the specific verb 'Search' and resource 'your Gmail', and distinguishes from the sibling gmail_read_email by mentioning it can be used with the returned ids.

  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?

  Explains when to use filters and that no filters returns recent emails. Provides date format and semantics. Could explicitly mention when not to use, but alternatives (gmail_read_email) are referenced for reading full messages.

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

• drive_searchA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that it returns id, name, type, owner, and last-modified time. It also explains the scope (own Drive vs. shared drives via include_shared_drives). It does not mention permission requirements, rate limits, or potential performance impacts of full-text search, but overall provides sufficient transparency for a search 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, well-structured paragraph. It begins with the core purpose, followed by filtering details, default behavior, parameter guidance, return format, and chaining to another tool. Every sentence adds value, with no redundancy or wasted words.

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

  Completeness5/5

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

  Given the input schema complexity (5 parameters, all optional) and the presence of an output schema (not shown but referenced), the description provides all necessary context. It covers filtering, default behavior, return fields, valid file types, and chaining. The only minor gap is an explicit mention of max_results, but its default and purpose are inferable.

  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 5 parameters with no descriptions (0% coverage). The description explains the purpose of name, content, file_type, and include_shared_drives parameters, and lists valid file_type values ('doc, sheet, slides, pdf, folder'). It covers max_results implicitly by mentioning 'most recently modified files' and default behavior, but does not explicitly describe the parameter. Overall, it adds significant meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states that the tool searches Google Drive files and shared drives, listing matches with filtering options. It distinguishes itself from siblings: drive_list_shared_drives focuses on listing shared drives, drive_read_file reads content using the returned id, and gmail tools are unrelated. The verb 'Search' plus resource 'Google Drive' and scope 'your files and shared drives' make the purpose specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description explains when to use the tool: for searching by file name, content, or type, and mentions default behavior (most recently modified files). It also directs using the id with drive_read_file for reading contents. However, it does not explicitly state when not to use this tool or list alternatives, though siblings like drive_list_shared_drives are implicitly distinguished.

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