Server Quality Checklist

Tool Scores

• copy_itemC
  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 'Copy' implies a non-destructive operation, it doesn't specify whether it preserves metadata, handles permissions, overwrites existing files, or returns any confirmation. For a mutation tool with zero 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.

  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 perfectly front-loaded with the core action and resource, making it immediately understandable without any 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 on success/failure, whether it returns confirmation or error details, or how it interacts with sibling tools. The agent lacks critical context for proper invocation and error handling.

  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 adequately. The description doesn't add any meaningful context about parameter semantics beyond what's in the schema (e.g., path formats, relative vs absolute paths, or special handling for directories). Baseline 3 is appropriate when 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 ('Copy') and resource ('a file or directory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'move_item' or explain what distinguishes copying from moving, 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 'move_item' or 'write_file'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with insufficient context for optimal tool selection.

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

• create_directoryC
  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 full burden. It mentions the 'parent directories if needed' behavior, which is useful, but lacks critical details like whether it overwrites existing directories, what permissions are required, error conditions, or what happens on success. 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 front-loads the core action ('Create a directory') and adds a clarifying detail ('and parent directories if needed') without waste. Every word earns its place.

  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 information on permissions, error handling, return values, or how it interacts with sibling tools like 'delete_directory'. Given the complexity of file system operations, more context is needed for safe and 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?

  Schema description coverage is 100% with one parameter 'path' documented as 'Directory path'. The description adds no additional parameter semantics beyond what the schema provides, such as path format examples or constraints. Baseline 3 is appropriate since 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 verb 'create' and resource 'directory' with the specific behavior 'and parent directories if needed'. It distinguishes from siblings like 'delete_directory' or 'copy_item' by focusing on creation, though it doesn't explicitly contrast with them.

  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, permissions needed, or when to choose this over other file operations like 'move_item' or 'write_file' for directory creation scenarios.

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

• delete_directoryC
  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 tool deletes a directory and its contents, implying a destructive mutation, but doesn't address critical aspects like permissions required, whether deletion is permanent or reversible, error conditions (e.g., non-existent path), or side effects. For a destructive tool, 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 with zero wasted words. It front-loads the core action ('Delete') and resource, making it immediately scannable. Every word earns its place by conveying essential information without 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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on permissions, safety warnings, return values, or error handling. For a tool that permanently removes data, more context is needed to ensure safe and correct usage by an 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 input schema already documents both parameters ('path' and 'recursive') adequately. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain path format, recursive behavior implications, or default values. Baseline 3 is appropriate when 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 ('Delete') and resource ('a directory and its contents'), making the purpose immediately understandable. It distinguishes from sibling tools like 'delete_file' by specifying directory deletion rather than file deletion. However, it doesn't explicitly contrast with other directory operations like 'create_directory' or 'move_item'.

  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., directory must exist), when not to use it (e.g., for non-empty directories without recursive flag), or direct alternatives like 'move_item' for relocation instead of deletion. The agent must infer usage from context alone.

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

• delete_fileC
  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 full burden for behavioral disclosure. 'Delete a file' implies a destructive mutation, but it doesn't specify whether deletion is permanent or reversible, what permissions are required, whether it works on read-only files, or what happens on failure. For a destructive 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 extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource. Every word earns its place by communicating the essential purpose without any fluff or 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?

  Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like safety warnings, error conditions, return values, or system-specific behaviors. The agent lacks sufficient information to use this tool responsibly without additional assumptions or trial-and-error.

  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 'path' parameter clearly documented in the schema. The description adds no additional meaning about the parameter beyond what the schema provides (e.g., no format examples, path resolution rules, or special cases). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

  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 ('Delete') and resource ('a file'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'delete_directory' by specifying file deletion rather than directory deletion. However, it doesn't specify whether this is permanent deletion or moves to trash/recycle bin, which would make it more specific.

  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., file must exist, user must have permissions), when not to use it (e.g., for directories use delete_directory), or how it differs from similar operations like move_item to trash. The agent must infer usage from the name alone.

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

• execute_commandC
  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. While 'execute a shell command' implies a potentially dangerous operation with security implications, the description doesn't mention permission requirements, security restrictions, whether commands run in a sandbox, or what happens with output/errors. The 'platform-aware' hint is useful but insufficient for a tool that could have significant behavioral consequences.

  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 6 words, with zero wasted language. It's front-loaded with the core purpose and includes a useful qualifier. Every word earns its place, making it easy for an agent to parse quickly while still conveying 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 potentially dangerous execution tool with no annotations and no output schema, the description is inadequate. It doesn't address security implications, permission requirements, error handling, output format, or execution environment. Given the complexity and risk profile of shell command execution, the description should provide much more context about behavioral constraints and expected outcomes.

  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 fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain what types of commands are supported, format requirements, or how 'platform-aware' affects parameter interpretation. Baseline 3 is appropriate when the schema does all the parameter documentation 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 ('execute') and resource ('shell command'), making the purpose immediately understandable. It adds the qualifier 'platform-aware' which provides useful context about cross-platform compatibility. However, it doesn't explicitly differentiate this from sibling tools like 'get_platform_info' or other execution-related tools that might exist.

  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 about when to use this tool versus alternatives. With siblings like 'get_platform_info' and various file operations, there's no indication whether this is for system-level commands, script execution, or how it differs from other tools that might execute code. The agent receives no usage context or exclusion criteria.

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

• get_file_infoC
  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 full burden for behavioral disclosure. 'Get information' implies a read-only operation, but it doesn't specify what information is returned (metadata, permissions, size, etc.), whether it works for both files and directories equally, error conditions (e.g., non-existent paths), or performance characteristics. The description is too vague to guide the agent 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 wasted words. It's front-loaded with the core purpose ('Get information about a file or directory'), making it immediately scannable and understandable. Every word earns its place without 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 lack of annotations and output schema, the description is incomplete for a tool with potential complexity. It doesn't explain what 'information' includes, how results are structured, or any behavioral nuances. For a read operation in a filesystem context with many sibling tools, more detail is needed to help the agent use it correctly without trial and error.

  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 'path' clearly documented in the schema as 'File or directory path'. The description adds no additional semantic context beyond what the schema provides—it doesn't clarify path format (absolute vs. relative), restrictions, or examples. Baseline 3 is appropriate since 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 verb ('Get information') and resource ('about a file or directory'), making the purpose immediately understandable. It distinguishes this from siblings like 'read_file' (which reads content) or 'list_directory' (which lists contents), but doesn't explicitly contrast with 'get_current_directory' or 'search_files' which might overlap in information retrieval.

  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 siblings like 'list_directory' (for directory contents), 'search_files' (for finding files), and 'get_current_directory' (for current location), there's no indication whether this tool is for metadata retrieval, existence checking, or other specific use cases. The agent must infer usage from the name alone.

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

• list_directoryC
  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 full burden for behavioral disclosure. While 'List contents' implies a read-only operation, it doesn't specify permissions needed, error handling (e.g., for non-existent paths), output format, or whether it's recursive. For a tool with no annotation coverage, this leaves significant behavioral gaps.

  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 and appropriately sized for a simple listing 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?

  Given no annotations, no output schema, and multiple sibling tools with overlapping functionality, the description is incomplete. It doesn't explain what 'contents' includes (files, directories, symlinks), how results are formatted, or how it differs from similar tools, leaving the agent with insufficient context for optimal 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%, with both parameters ('path' and 'showHidden') fully documented in the schema. The description adds no additional parameter semantics beyond what's already in the structured fields, 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 'List contents of a directory' clearly states the verb ('List') and resource ('contents of a directory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_current_directory' or 'search_files' which also involve directory/file operations, so it doesn't reach the highest 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. With siblings like 'get_current_directory' (which might list current directory) and 'search_files' (which might filter results), there's no indication of when 'list_directory' is preferred or what its specific scope is beyond the basic listing function.

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

• move_itemC
  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 'move or rename' implies mutation/destructive action, it doesn't specify whether the operation is atomic, reversible, requires specific permissions, affects linked references, or has rate limits. For a mutation 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 perfectly concise - a single sentence with zero wasted words that immediately communicates the core functionality. It's front-loaded with the essential information and earns its place efficiently.

  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 insufficiently complete. It doesn't address important contextual aspects: what happens on success/failure, whether the operation overwrites existing files, how to handle cross-device moves, or what the return value contains. The agent lacks critical information for proper tool invocation.

  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 ('source path' and 'destination path'). The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain path formats, relative vs absolute paths, or rename semantics when source and destination differ only in name. Baseline 3 is appropriate when 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 tool's purpose with specific verbs ('move or rename') and resources ('file or directory'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'copy_item' (which copies rather than moves) or 'rename' functionality that might be implied in other tools.

  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 when to choose 'move_item' over 'copy_item' (for moving vs copying), when renaming might be preferable to moving, or any prerequisites like needing appropriate permissions. The agent must infer usage from the name alone.

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

• read_fileC
  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. While 'Read contents' implies a read-only operation, it doesn't specify permissions required, error handling (e.g., for missing files), or output format (e.g., raw text vs. structured data). For a tool with 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 directly states the tool's function without unnecessary words. It is front-loaded with the core purpose ('Read contents of a text file'), making it easy to parse. Every word earns its place, with no redundancy or fluff.

  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 file-reading tool. It doesn't address key contextual aspects like what happens if the file doesn't exist, if binary files are handled, or what the return value looks like (e.g., string content). For a tool with 2 parameters and no structured output documentation, more detail 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?

  The schema description coverage is 100%, with both parameters ('path' and 'encoding') clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as path format examples or encoding options. 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 ('Read contents') and resource ('text file'), making the purpose immediately understandable. However, it doesn't differentiate from potential siblings like 'get_file_info' or 'search_files' which might also involve reading file content or metadata. The description is specific but lacks 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. With siblings like 'get_file_info' (which might return metadata) and 'search_files' (which might search content), there's no indication of when 'read_file' is the appropriate choice. No exclusions or prerequisites are mentioned.

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

• search_filesC
  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. While 'search' implies a read-only operation, it doesn't specify whether this is recursive (implied by maxDepth parameter but not stated), case-sensitive, or what happens on errors (e.g., invalid path). It also doesn't describe the return format (e.g., list of file paths, metadata) or performance characteristics. For a tool 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and avoids unnecessary elaboration. Every word earns its place, 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?

  Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on return values (critical for a search tool), error handling, recursion behavior, and usage context. Without an output schema, the description should at least hint at what's returned (e.g., 'returns matching file paths'), but it doesn't. This leaves significant gaps for an agent to 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?

  Schema description coverage is 100%, with clear descriptions for all three parameters (path, pattern, maxDepth). The description adds no additional parameter semantics beyond what's in the schema—it mentions 'name pattern' which aligns with the 'pattern' parameter but provides no extra details about wildcard syntax, format, or examples. Baseline 3 is appropriate when 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 'Search for files by name pattern' clearly states the verb (search) and resource (files) with a specific method (by name pattern). It distinguishes from siblings like list_directory (which lists without searching) and get_file_info (which retrieves metadata for a specific file). However, it doesn't explicitly mention the scope (e.g., recursive search) or differentiate from potential pattern-based 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer search_files over list_directory (for pattern matching vs. simple listing) or get_file_info (for finding specific files vs. retrieving metadata). There's no context about prerequisites, exclusions, or typical use cases.

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

• write_fileC
  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. 'Write content to a file' implies a mutation operation, but it doesn't specify critical details like whether it overwrites existing files, requires specific permissions, handles errors, or has side effects. 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 extremely concise with a single, direct sentence ('Write content to a file') that efficiently communicates the core purpose without any wasted words. It's front-loaded and appropriately sized 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 a file write operation with no annotations and no output schema, the description is incomplete. It lacks details on behavior (e.g., overwrite vs. append), error handling, or return values, which are essential for an agent to use this tool effectively in a filesystem context.

  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 all three parameters (path, content, encoding) with descriptions. The description doesn't add any additional meaning beyond what the schema provides, such as explaining parameter interactions or constraints, which aligns with the baseline score 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 ('write') and resource ('content to a file'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_directory' or 'move_item' beyond the basic verb+resource pairing, 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?

  No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'create_directory' for file creation or how it relates to 'read_file' for file operations. The description offers no context about prerequisites or exclusions.

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

• get_current_directoryB
  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 what the tool does but doesn't describe how it behaves—for example, whether it returns a string path, what happens if there's no current directory, or if it requires specific permissions. This leaves significant gaps for an agent to understand the tool's 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?

  The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose, making it highly efficient and easy to parse for an AI agent.

  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 simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, it lacks context about return values or behavioral nuances, which could be important for integration. With no annotations or output schema, more detail would improve completeness for agent use.

  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 there's no need for parameter documentation in the description. The baseline for this scenario is 4, as the description appropriately doesn't waste space on non-existent parameters, though it doesn't add extra value beyond 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 states the verb ('Get') and resource ('current working directory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_file_info' or 'get_platform_info' that also retrieve information, so it doesn't reach the highest 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 context like needing to know the current directory for navigation or file operations, nor does it reference sibling tools like 'list_directory' that might serve similar purposes in different scenarios.

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

• get_platform_infoB
  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 retrieves information, implying a read-only operation, but doesn't specify details like authentication requirements, rate limits, or what 'allowed paths' entails. This leaves significant gaps in understanding 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 that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 (0 parameters, no output schema) and lack of annotations, the description is minimally adequate. It explains what the tool does but lacks details on behavior, usage context, or output format, which could be helpful 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.

  Parameters4/5

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

  The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('information about the current platform and allowed paths'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate itself from sibling tools like 'get_current_directory' or 'get_file_info', 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. With siblings like 'get_current_directory' and 'get_file_info' that also retrieve information, there's no indication of when this tool is preferred or what specific context it serves, leaving usage unclear.

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