Server Quality Checklist

Tool Scores

• get_file_infoC
  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 'detailed information' but doesn't specify what that includes (e.g., metadata, permissions, size), whether it requires authentication, has rate limits, or how errors are handled. This leaves significant gaps for a tool that likely interacts with external systems.

  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 appropriately concise with two sentences: one stating the purpose and another explaining the parameter. It's front-loaded with the core functionality, though the parameter explanation could be integrated more smoothly rather than as a separate 'Args:' section.

  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 low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on behavioral aspects like error handling or system interactions, and with no annotations, it doesn't fully compensate for the schema's 0% description coverage.

  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 adds minimal semantics beyond the input schema: it clarifies that 'file_path' is a 'Full path to the file in Dropbox', which provides context not in the schema (which has 0% description coverage). However, it doesn't elaborate on path format, constraints, or examples, leaving the schema to define the parameter type without richer guidance.

  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 tool's purpose as 'Get detailed information about a specific file' with a specific verb ('Get') and resource ('file'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'read_file' beyond the general concept of retrieving information rather than listing or reading content.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_files', 'read_file', or 'search_files'. It mentions the 'file_path' parameter but doesn't clarify 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.

• search_file_contentC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool does but lacks details on permissions, rate limits, error handling, or output format. For a search operation with no annotation coverage, this is a significant gap in transparency about how the tool behaves beyond basic functionality.

  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 appropriately sized and front-loaded, with a clear purpose statement followed by parameter details in a structured format. Every sentence adds value, though it could be slightly more concise by integrating parameter explanations more seamlessly. Overall, it's efficient 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?

  Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameters but lacks usage guidelines, behavioral details, and differentiation from siblings. The output schema existence reduces the need to explain return values, but other gaps remain, making it adequate but with clear room for improvement.

  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 0%, so the description must compensate. It lists parameters with brief explanations ('List of file paths to search in', 'Text to search for', 'Number of characters of context around matches'), adding some meaning beyond the schema's property names. However, it doesn't specify formats (e.g., file path syntax), constraints, or examples, leaving gaps in understanding.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Search for text within specific files.' This is a specific verb ('search') with resource ('text within specific files'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_files' (which might search file names/metadata vs. content), leaving some ambiguity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_files', 'get_file_info', 'list_files', and 'read_file', there's no indication of how this tool differs in use cases, prerequisites, or exclusions. This lack of context makes it hard for an agent to choose appropriately.

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

• search_filesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for files but does not cover critical aspects like authentication requirements, rate limits, pagination behavior, or error handling. For a search tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is front-loaded with a clear purpose statement, followed by a structured 'Args' section that efficiently lists parameters. Each sentence adds value without redundancy, though it could be slightly more concise by integrating the parameter explanations into the main text.

  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 moderate complexity (3 parameters, no annotations, but with an output schema), the description is adequate but incomplete. It covers basic functionality and parameters but lacks behavioral details (e.g., search scope, result format hints). The presence of an output schema reduces the need to explain return values, but more context on usage and limitations would improve completeness.

  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 description adds meaningful context beyond the input schema, which has 0% schema description coverage. It explains that 'query' searches file names and content, 'file_types' accepts specific values or a comma-separated list, and 'max_results' limits returned results. This compensates well for the lack of schema descriptions, though it could detail format constraints (e.g., query syntax).

  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 tool searches for files in Dropbox by name or content, providing a specific verb ('search') and resource ('files in Dropbox'). However, it does not explicitly differentiate from sibling tools like 'search_file_content' or 'list_files', which may have overlapping functionality, leaving some ambiguity about when to choose this tool over others.

  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_file_content'. It mentions searching by name or content but does not specify scenarios, prerequisites, or exclusions, leaving the agent to infer usage from context without explicit direction.

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

• list_filesB
  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 the tool lists files and folders, implying a read-only operation, but does not disclose any behavioral traits such as permissions needed, rate limits, pagination, or what happens with invalid paths. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, with a clear purpose statement followed by concise parameter explanations. Every sentence earns its place, and there is no wasted text, making it efficient and well-structured for quick understanding.

  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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters but lacks behavioral details and usage guidelines. The presence of an output schema means the description need not explain return values, but other gaps (e.g., no sibling differentiation) keep it at a baseline adequacy level.

  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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'folder_path' is the 'Path to the folder (empty string for root)' and 'max_files' is the 'Maximum number of items to return,' providing context not present in the schema. With two parameters and low schema coverage, this compensation is effective, though not exhaustive (e.g., no format details for paths).

  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 tool's purpose: 'List files and folders in a Dropbox directory.' It specifies the verb ('List') and resource ('files and folders in a Dropbox directory'), making the action and target explicit. However, it does not distinguish this tool from its siblings (e.g., search_files or get_file_info), which reduces the score from a 5.

  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 mentions the parameters but does not specify contexts for usage, exclusions, or comparisons with sibling tools like search_files or get_file_info. This lack of explicit when/when-not/alternatives guidance results in a low score.

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

• read_fileA
  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 states the tool reads and returns file content, which implies a read-only operation, but doesn't mention permissions needed, rate limits, file size limitations, or error conditions. The description adds basic context but lacks important behavioral details for a file access 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 perfectly structured with a clear purpose statement followed by parameter explanations. Every sentence earns its place: the first sentence states the core functionality, and the parameter descriptions are essential for understanding usage. No wasted words or 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 the tool's moderate complexity (file reading with truncation), no annotations, and the existence of an output schema (which handles return value documentation), the description is reasonably complete. It covers the purpose and parameters well, though it could benefit from more behavioral context about limitations or error handling.

  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?

  With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It provides meaningful explanations for both parameters: 'file_path' as 'Full path to the file in Dropbox' and 'max_length' as 'Maximum characters to return (0 for no limit)', which adds substantial value beyond the bare 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 the specific action ('Read and return the full content') and the resource ('a file'), distinguishing it from siblings like get_file_info (metadata), list_files (directory listing), and search_file_content/search_files (search operations). The verb+resource combination is precise 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 implies usage for reading file content, but doesn't explicitly state when to use this tool versus alternatives like get_file_info (for metadata) or search_file_content (for searching within files). It provides clear context for reading full content, but lacks explicit exclusions or named alternatives.

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