Server Quality Checklist

Tool Scores

• get_file_contentC
  2.7/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 mentions the action ('Get content') and supported file types, but lacks critical details such as authentication requirements, rate limits, error handling (e.g., for unsupported formats), or what the output looks like (e.g., raw text, structured data). For a read operation with no 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.

  Conciseness4/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 ('Get content from a Google Drive file') and adds specific details (file types). There's no wasted verbiage, making it appropriately concise for the tool's complexity.

  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 (2 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and file types but misses essential context: parameter explanations, behavioral traits (e.g., read-only nature, potential errors), and output details. Without annotations or output schema, the description should do more to guide the agent.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't explain the meaning or usage of 'driveId' and 'fileId' parameters (e.g., how to obtain them, their format, or that 'driveId' is optional). The mention of file types implies some parameter context but doesn't directly address the input schema, leaving key semantics unclear.

  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 content') and resource ('from a Google Drive file'), making the purpose understandable. It also specifies supported file types (Docs, Sheets, TXT, MD), which adds useful detail. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'search_files', which might also involve file content access.

  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 file permissions), exclusions (e.g., unsupported file types beyond those listed), or comparisons to siblings like 'search_files' for content-based queries. 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.

• search_filesC
  2.8/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 'search' implies a read-only operation, it doesn't specify whether this requires authentication, what happens with no results, whether there are rate limits, or how results are returned. The description mentions the scope ('in a Google Drive') but lacks other critical behavioral context 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a basic search tool and gets straight to the point with no wasted language.

  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 search tool with 2 required parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how results are structured, whether there are limitations on search scope, or how to interpret the parameters. The description provides only basic purpose information without the necessary context for effective tool usage.

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

  Parameters2/5

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

  With 0% schema description coverage for both parameters, the description provides no information about what 'driveId' and 'query' represent, their formats, or constraints. The description mentions 'search files by name' which hints that 'query' might be a filename search, but doesn't clarify if it supports partial matches, wildcards, or other search operators. This doesn't adequately compensate for the complete lack of schema documentation.

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

  Purpose4/5

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

  The description clearly states the action ('search files by name') and resource ('in a Google Drive'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'list_files', but the 'search by name' specification provides some differentiation from a generic listing 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 'list_files' or 'get_file_content'. It doesn't mention prerequisites, limitations, or specific scenarios where this search function is appropriate versus other file-related operations.

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

• add_driveC
  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 'Add' implies a write/mutation operation but doesn't cover critical aspects like whether this requires admin permissions, if it's idempotent, what happens on duplicate driveId, or error handling. For a configuration tool with zero annotation coverage, 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.

  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 adding a Google Drive account (involving authentication via service accounts) and the absence of both annotations and an output schema, the description is insufficient. It doesn't explain what 'configuration' means, what the tool returns (e.g., success confirmation or error), or how it integrates with sibling tools. For a mutation tool with no structured support, 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%, so the input schema fully documents all parameters (driveId, name, serviceAccountPath, description). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when the 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 action ('Add') and resource ('new Google Drive account to the configuration'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_drives' or 'remove_drive', which would require mentioning it's for configuration setup rather than data operations.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'list_drives' for viewing existing drives or 'remove_drive' for deletion. The description lacks context about prerequisites (e.g., needing a service account file) or typical scenarios (e.g., initial setup vs. adding multiple drives).

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

• list_filesC
  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 mentions optional filters but doesn't describe key behaviors: whether this is a read-only operation, how pagination works (though 'pageSize' is in schema), what the return format looks like, or any rate limits/permissions needed. For a tool with 6 parameters and 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 front-loads the core purpose ('List files from Google Drive') and then enumerates optional filters. There is zero wasted language, and every word contributes directly to understanding the tool's functionality.

  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 has 6 parameters with 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, pagination behavior, error conditions, or how filters interact. For a listing tool with multiple filters, more context is needed 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 description lists 5 of the 6 parameters (driveId, folderId, mimeType, modifiedAfter/Before) as optional filters, adding meaning beyond the schema which has 0% description coverage. However, it omits 'pageSize' entirely, and doesn't explain parameter formats (e.g., date format for modifiedAfter) or relationships between parameters. With low schema coverage, it partially compensates but not fully.

  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 'files from Google Drive', making the purpose unambiguous. It distinguishes from siblings like 'search_files' by specifying it's a listing operation rather than a search, though it doesn't explicitly contrast them. The description avoids tautology by not just repeating the name.

  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_files' or 'list_drives'. It mentions optional filters but doesn't explain scenarios where filtering is appropriate or when other tools might be better suited. There are no explicit when/when-not instructions or named alternatives.

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

• remove_driveC
  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 but only states the action without behavioral details. It doesn't disclose if removal is destructive, reversible, requires specific permissions, affects associated data, or has side effects like rate limits, which is inadequate 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, direct sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for a simple tool, 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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like what 'remove' entails (e.g., permanent deletion, configuration update), success/failure behavior, or error handling, 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 already documents the 'driveId' parameter fully. The description adds no additional meaning beyond implying the parameter identifies the drive to remove, meeting the baseline for high schema coverage without extra 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 clearly states the action ('Remove') and resource ('Google Drive account from the configuration'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_drive' beyond the obvious verb contrast, missing explicit scope or relationship context.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing drive), exclusions, or how it relates to siblings like 'list_drives' for selection or 'add_drive' for reversal, leaving usage context implied at best.

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

• list_drivesB
  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 of behavioral disclosure. It states it lists drives but doesn't cover aspects like authentication requirements, rate limits, pagination, or what 'configured' entails. This leaves significant gaps for a tool that likely interacts with external services.

  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 unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.

  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 has 0 parameters and no output schema, the description is minimally adequate but incomplete. It lacks details on behavioral aspects like authentication or return format, which are important for a tool listing external resources. The absence of annotations increases the need for more context.

  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%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could slightly clarify the scope of 'configured' (e.g., user-specific vs. system-wide).

  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 ('Google Drive accounts') with the scope modifier 'all configured', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'search_files', which might also involve listing operations.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_files' or 'search_files', nor does it mention prerequisites such as needing configured drives first. It lacks explicit context or exclusions, leaving usage ambiguous.

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