Server Quality Checklist

Tool Scores

• replace_in_fileC
  2.6/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 responsibility for behavioral disclosure. It does not state whether the replacement is atomic, case-sensitive, line-based, or whether it handles special characters. Key traits like side effects (modifying disk), failure modes (file not found, permission denied, no matches), and idempotency are entirely omitted.

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

  Conciseness3/5

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

  The description is extremely short (one sentence, 8 words) – it sacrifices completeness for brevity. It is front-loaded with the verb 'Replace', which is good, but the sentence fails to earn its place because it omits critical context that would only add a few more words (e.g., 'exact', 'in existing file').

  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 that there are 19 sibling file-manipulation tools and an output schema exists, the description should clarify what the tool returns (success indicator? list of replacements?), how it interacts with other tools (e.g., conflict with write_file), and edge-case behavior. It is severely incomplete for a file-modification tool that can have destructive effects.

  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?

  The schema already describes each parameter with basic names and types (path, old, new as strings). The description adds no semantic nuance beyond repeating the parameter roles. It fails to clarify scope: for example, does 'old' match partial substrings or whole words? Does 'new' support escaped characters or newlines? With 100% schema coverage, the baseline is 3, but the description underperforms by not enriching interpretation.

  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 ('replace all occurrences'), the target ('file'), and the operation's scope ('all occurrences of old with new'). It distinguishes from siblings like write_file, which would overwrite the entire file, and append_file, which adds text. However, it doesn't explicitly clarify that this is a text-based search-and-replace (not regex) and lacks a caution about potential partial matches or text within larger words.

  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 its many siblings. For example, the description does not explain that replace_in_file is for simple exact-text substitutions, while search_text might be used to preview matches first, or that write_file is preferable for full rewrites. There is no mention of prerequisites (e.g., file must exist) or when to avoid it (e.g., binary files).

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

• copy_fileC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'copy a file' without revealing overwrite behavior, metadata handling, error cases, or whether the operation is safe/unsafe. The schema's mention of parent folder creation is not in the description, so the description adds no behavioral context.

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

  Conciseness3/5

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

  The description is a single sentence, which is concise, but it merely restates the tool name and offers no additional value. It is front-loaded with the verb but is too short to earn its place as a helpful supplement – borderline under-specified.

  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?

  Even for a simple file operation, the description is incomplete. It does not cover return values (though output schema exists), error conditions, idempotency, or side effects like overwriting. The 2 required params and lack of annotations demand richer context, which is missing.

  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 (src and dst). The description adds no additional meaning beyond the schema, earning a baseline 3. It neither enriches nor detracts from parameter 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 action (copy) and resource (file) with a destination, making the primary purpose obvious. However, it does not differentiate from sibling tools like 'move_file' or differentiate copying vs. moving, losing a point for lack of 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?

  No guidance is provided on when to use this tool over alternatives such as move_file, write_file, or append_file. There are no exclusions, prerequisites, or context signals to help the agent select it appropriately.

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

• move_fileC
  2.9/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries full responsibility for disclosing behavioral traits. The description only states the core action; it omits important details such as whether the source is deleted after move, overwrite behavior on destination, required permissions, error handling (e.g., non-existent src), or side effects (e.g., creating parent folders, which is noted in the schema but not in the description).

  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, well-structured sentence that front-loads the core purpose. However, it is so brief that it sacrifices completeness; it would benefit from one or two additional sentences to cover essential behavioral notes. The conciseness is commendable but edges toward under-specification.

  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?

  The description is minimal and lacks context about the operation's effects (e.g., atomicity, overwriting), error conditions, and relationship to sibling tools. An output schema exists (not shown) which somewhat reduces the need to describe return values, but the agent still lacks enough context to confidently use the tool in complex workflows.

  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 coverage is 100% and the schema already documents both parameters (src, dst) with descriptions. The tool description adds no additional meaning or context about the parameters, such as path format constraints or typical usage patterns. Baseline 3 is appropriate since the schema bears the burden adequately.

  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 'Move or rename a file or folder' clearly states the action (move/rename) and resource (file/folder). It distinguishes from siblings like copy_file by implication of the verb, but does not explicitly contrast with alternatives such as rename vs move behavior (e.g., overwrite policy).

  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 vs alternatives (e.g., copy_file, delete_file, rename). The description does not mention prerequisites, limitations, or contextual exclusions. With a large sibling set, this omission reduces usability for an AI agent deciding which tool to invoke.

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

• python_fileC
  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. It does not disclose key behaviors: whether output (stdout/stderr) is captured, error handling, timeout, side effects, or that it uses the current Python environment. The existence of an output schema is not mentioned or explained.

  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, front-loaded sentence with no fluff. However, it is slightly underspecified for the complexity of executing a script file; one more sentence could add behavioral detail without losing conciseness.

  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 executes a Python script, important details are missing: return format (stdout/exit code), error behavior, and how it differs from running inline code. The output schema exists but description ignores it. For a simple tool with one param, the description is incomplete.

  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% for the single parameter 'file', which is already described as 'Path to the .py file to run.' The description adds no extra context about path resolution, relative vs absolute, or format. Baseline 3 is appropriate as 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 'Execute' and resource 'Python script file', distinguishing it from sibling tools like 'python_code' (inline code) and 'run_command' (arbitrary commands). However, it does not explicitly differentiate, and the phrase 'with the running interpreter' is slightly ambiguous.

  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 'python_code' or 'run_command'. There are no prerequisites, exclusions, or context for appropriate use, leaving the agent to infer 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.

• append_fileB
  3.3/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 responsibility. It discloses the auto-creation behavior, but omits other important traits such as whether parent directories are created, encoding handling, error conditions (e.g., path is a directory), or output format. The presence of an output schema is indicated but not described.

  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 sentence of 10 words, highly concise and front-loaded. Every word contributes meaning without redundancy.

  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 that an output schema exists (but is not shown), the description does not need to document return values. However, in the context of many sibling file tools, the description lacks details like whether content is appended with a newline, how creation handles directory structure, and any side effects. It is minimally complete for a straightforward append operation.

  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 minimal descriptions ('Destination path.', 'Text to append.'). The tool's description adds no further semantic detail about the parameters beyond what the schema already provides, so a baseline score of 3 is appropriate.

  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 uses a specific verb ('append') and resource ('a file'), and adds the behavior of creating the file if needed. This clearly distinguishes it from sibling tools like 'write_file' (overwrite) and 'replace_in_file' (pattern-based modification).

  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 does not provide any guidance on when to use this tool versus alternatives. While the name and sibling list suggest the difference, there is no explicit statement of when to choose 'append_file' over 'write_file' or 'replace_in_file'.

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

• delete_folderB
  3.3/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 responsibility for disclosing behavioral traits. While it indicates a destructive action ('delete') and recursive scope, it fails to mention irreversibility, permission requirements, or error states (e.g., folder not found, non-empty). This is minimal transparency 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, unduttered sentence of four words. There is no wasted text, and the critical verb and noun are front-loaded. For a simple tool with one parameter, this is optimally concise.

  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 simplicity of the tool (one required parameter), the description is minimally adequate. However, it omits important context such as error handling, side effects, or the implication that deletion is irreversible. The existance of an output schema partly mitigates the need to describe return values, but behavioral gaps remain.

  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 provides 100% coverage with a clear description ('Path of the folder to delete.'). The tool description adds no additional meaning about the parameter – it only describe the operation. Following guidelines, baseline 3 is appropriate when schema already covers all parameters.

  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 action ('delete') and the resource ('folder'), and the term 'Recursively' clarifies the scope. This distinguishes it from sibling tools like delete_file (which targets files) and create_folder (opposite action). It is 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 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 (e.g., delete_file for folders vs files) or any prerequisites or conditions. There is no mention of when-not-to-use or potential consequences, leaving the agent without decision support.

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

• get_env_varB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It does not state what happens if the variable is unset (e.g., returns null, undefined, or errors), whether it returns a string or other type, or any side effects. Given the lack of annotations, 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, concise sentence that directly conveys the purpose with no redundancy or unnecessary detail. It is front-loaded and every word earns its place.

  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?

  For a simple read-only tool with one parameter and 100% schema coverage, the description is minimal but sufficient to convey basic intent. However, with no annotations, the lack of behavior for edge cases (e.g., unset variable) reduces completeness. An output schema exists, reducing the need to describe return format, so this is adequate yet not rich.

  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 parameter 'name' is already documented in the schema. The description adds no further semantics beyond what is provided. Baseline 3 is appropriate as the schema covers the parameter 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 tool's purpose: 'Return the value of an environment variable.' It uses a specific verb ('return') and resource ('environment variable'), distinguishing it from siblings that operate on files or run commands. Although it lacks explicit mention of scoping (e.g., whether it works across sessions), the purpose is unambiguous.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (to retrieve an environment variable's value) but does not provide guidance on when not to use it or alternatives. It does not mention any prerequisites or context (e.g., whether the variable must be set beforehand or if it works in the same session). This is adequate but lacks explicit usage exclusions.

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

• python_codeB
  3.4/5.0
  Behavior3/5

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

  No annotations provided, so the description carries full burden. It states execution with 'the running interpreter' implying shared state and side effects, but does not specify if state is isolated, whether prints are captured, or if destructive operations are dangerous. Basic utility disclosure is minimal.

  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?

  Extremely concise: one sentence containing the essential action and context. No wasted words, though could add guidance without losing conciseness.

  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?

  With an output schema present, the description need not detail return values. However, given the tool's open-ended nature (executing arbitrary code), the description lacks warnings about side effects, security context, or isolation. Adequate but not complete for risk-aware usage.

  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 a single parameter 'code' described as 'The Python source to execute.' The description adds no additional semantic meaning beyond this, so baseline 3 is appropriate.

  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 'Execute a Python snippet' which defines the action and resource precisely. However, it does not distinguish from sibling tools like 'python_file' which executes a Python file rather than a snippet, but the difference is implicit.

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

  Usage Guidelines3/5

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

  No explicit guidance on when to use this tool versus alternatives like 'python_file' or 'run_command'. The description implies usage for ad-hoc Python snippets, but lacks when-not-to-use or exclusion criteria.

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

• treeB
  3.4/5.0
  Behavior2/5

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

  No annotations are present, so the description must fully disclose behavioral traits. It only states the basic operation (showing a tree) and references depth, but does not address read-only nature, error behavior (e.g., invalid path), or performance implications for large directories.

  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 conveys the tool's purpose without extraneous words. It is front-loaded and every word earns its place.

  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?

  The tool is simple with two optional parameters and an output schema. The description covers the core functionality. Minor omissions like read-only confirmation or handling of hidden files are acceptable given the low complexity.

  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 already described. The description adds no new meaning beyond the schema, so the baseline score of 3 applies.

  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 verb 'Show' and the resource 'directory structure', indicating a tree view. It distinguishes from sibling tools like list_dir (flat list) and glob_files (pattern matching) by specifying a hierarchical display.

  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 such as list_dir or glob_files. The description does not mention context 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.

• delete_fileA
  3.5/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. 'Delete' implies destructive action, but the description does not mention whether the file is permanently deleted (vs. moved to trash), what happens on error (non-existent path, permissions), or if it can be undone. A simple warning about irreversibility would improve 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 with one sentence and zero waste. Every word earns its place.

  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 1 parameter, full schema coverage, and an output schema (likely indicating success/failure), the description could add more context about return value or error handling. It is minimally adequate but lacks behavior details for a destructive operation.

  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 coverage is 100% (path described in schema). The description adds no extra meaning beyond what's in the schema. Baseline 3 is appropriate because schema already documents the parameter well.

  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 'Delete a single file.' uses a clear verb (delete) and specific resource (single file). It distinguishes from sibling 'delete_folder' and other file operations like 'move_file' or 'copy_file'.

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

  Usage Guidelines3/5

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

  The description implies usage for deleting individual files, but provides no guidance on when not to use it (e.g., instead of 'run_command' rm or other batch deletion), no prerequisites (file must exist), and no alternatives mentioned.

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

• read_fileA
  3.5/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 traits. The description only states it reads as UTF-8 text, but does not disclose whether the file may be binary, what happens with very large files, required permissions (e.g., file must exist, be accessible), or any side effects (none expected since it's read-only). For a read operation, the lack of explicit safety confirmation (e.g., 'This operation is read-only') is a 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 sentence of 7 words, with no wasted text. It is front-loaded with the core purpose. Every word earns its place by stating the action, resource, and encoding.

  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 has only one parameter, no annotations, and a single sibling 'read_file_lines' that provides a natural alternative, the description is reasonably complete. However, it lacks information about the output schema (which is available but not referenced) and error conditions (e.g., file not found). The agent might need to infer these from the tool name and 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?

  Schema coverage is 100% with a single required parameter 'file' described as 'Path of the file to read'. The description adds a slight nuance by stating 'UTF-8 text', implying the file should be a UTF-8 encoded text file. However, it does not clarify whether the path is absolute or relative (though the sibling 'get_cwd' hints at relative context), or whether it supports wildcards. The description adds marginal 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 'Read a file's contents as UTF-8 text', which has a specific verb ('Read'), a resource ('file'), and a format detail (UTF-8). This distinguishes it from sibling tools like 'read_file_lines' (which reads only lines) and 'file_info' (which reads metadata). However, it does not explicitly mention that it returns the full file content, leaving a slight ambiguity about the output structure.

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

  Usage Guidelines3/5

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

  The description implies the tool is for reading entire file contents, which is a common use case. It does not provide explicit guidance on when to use it vs alternatives like 'read_file_lines' (for line-by-line), 'grep' (for search within file), or 'replace_in_file' (for editing). No exclusions or prerequisites are mentioned, so the agent must infer context from sibling names.

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

• read_file_linesA
  3.5/5.0
  Behavior4/5

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

  The description explicitly states that out-of-range numbers are clamped to the file's actual length, which is a key behavioral detail beyond the input schema. Since no annotations are provided, the description adequately fills this 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 extremely concise with only two sentences, both providing essential information without any wasted words. The key behavior (clamping) is front-loaded in the second sentence.

  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 there is an output schema, the return values don't need explanation. However, the tool reads from a file but doesn't mention error cases (e.g., file not found, permissions), and with 3 required parameters, some context about the range format would be helpful for agents.

  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 input schema already provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds minimal semantic value beyond confirming the 1-based inclusive range and clamping behavior.

  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 specifies the verb 'Read' and the resource 'lines from a file,' and it clarifies the range is 1-based and inclusive. However, it doesn't differentiate from siblings like 'grep' or 'read_file' which also read file 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?

  No guidance is provided on when to use this tool versus siblings like 'read_file' for the whole file, 'grep' for pattern matching, or other tools. 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.

• file_infoA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states what is returned, but does not mention whether it follows symlinks, what happens if the path does not exist, permission requirements, or that it is a read-only 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 sentence of 12 words, front-loaded with the core purpose. Every word adds value with no redundancy or fluff.

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

  Completeness4/5

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

  For a simple tool with one parameter and an output schema, the description covers the essential functionality and return value. However, it does not mention error behavior (e.g., missing path) or that the output schema may contain additional fields beyond the examples.

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

  Parameters4/5

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

  Schema coverage is 100% (one parameter described as 'Path to inspect.'). The description adds value by clarifying that the tool works on both files and folders and lists the returned metadata fields, which enriches the schema's minimal description.

  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 uses a specific verb ('Return') and resource ('metadata about a file or folder'), and lists the types of metadata (type, size, modified time). This clearly distinguishes it from sibling tools like 'read_file' (reads content) or 'list_dir' (lists directory contents).

  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 gives no guidance on when to use this tool versus alternatives (e.g., when to use 'file_info' instead of 'glob_files' or 'list_dir'). It does not mention prerequisites, limitations, or when not to use it.

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

• list_dirA
  3.7/5.0
  Behavior3/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 states 'sorted' and shows output includes name and type. However, it doesn't disclose behavior on errors (e.g., invalid path, permissions), recursion depth, or whether hidden files are included. The output schema exists but isn't described here.

  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?

  One short sentence with no wasted words. Front-loaded with verb and resource, includes key behavior (sorted, includes name and type). Perfectly concise for a simple tool.

  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 there's an output schema and only one parameter, the description is mostly complete. It covers the main purpose and behavior. Could mention error handling or hidden file behavior for full completeness, but not critical.

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

  Parameters4/5

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

  Schema coverage is 100% with one parameter (path) having a clear description and default. The description adds context that listing includes 'name and type, sorted', which goes 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 tool lists directory contents (name and type, sorted). This distinguishes it from siblings like tree (recursive) and file_info (single file). However, it could be more precise about the type of the result (e.g., array of objects) and that it's non-recursive.

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

  Usage Guidelines3/5

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

  The description implies basic directory listing usage but doesn't explicitly state when to use versus alternatives like tree (for recursive listing) or glob_files (for pattern matching). No when-not-to-use guidance is given.

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

• search_textA
  3.7/5.0
  Behavior3/5

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

  While no annotations exist, the description discloses recursive behavior and automatic skipping of build/venv/cache directories. It does not explicitly state read-only nature, file type handling, or performance implications, leaving some ambiguity.

  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, both front-loaded with purpose and key behavioral note. Every word earns its place; no redundancy or filler.

  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 an output schema exists, the description doesn't need to detail return values. It covers core behavior and a notable filtering caveat. Missing clarification on whether pattern is regex or substring beyond the schema field description.

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

  Parameters4/5

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

  Schema coverage is 100%, but the description adds value by indicating the search is recursive and that certain directories are skipped—context beyond the parameter descriptions. This helps the agent understand how the directory parameter behaves.

  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 it recursively searches files for a pattern, using specific verb and resource. However, it does not differentiate from the sibling tool 'grep', which may have overlapping functionality.

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

  Usage Guidelines3/5

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

  Implied usage is for searching text in files recursively, with auto-skipping of common directories. No explicit guidance on when to use this versus alternatives like grep (e.g., for regex) or glob_files.

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

• create_folderA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description bears full responsibility for behavioral disclosure. It reveals one key trait (recursive parent folder creation) but omits other important behaviors: whether it fails or succeeds if the folder already exists, error handling for invalid paths, permission requirements, and what the output schema returns. The added parent-folder detail is valuable but insufficient for complete 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 a single, front-loaded sentence of just 6 words. It places the core verb ('Create') and resource ('a folder') first, then adds the essential detail about parent folders. There is zero wasted text; every word earns its place.

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

  Completeness4/5

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

  For a tool with one simple parameter and an output schema (not shown here but exists), the description covers the primary action and the key behavioral nuance. It does not explain error states, path validation, or idempotency, but given the low complexity and presence of an output schema to handle return values, the description is reasonably complete.

  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 schema describes the 'folder' parameter as 'Path of the folder to create.' The description adds meaning by stating 'including parent folders if needed,' which implies the parameter can include deep paths and the tool will create intermediates. This enriches the schema definition and clarifies the tool's behavior beyond the raw schema text.

  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 creates a folder ('Create a folder') and adds the critical detail about recursive parent folder creation ('including parent folders if needed'). This verb+resource specification differentiates it from sibling tools like delete_folder (destruction) and write_file (content creation).

  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 (e.g., write_file might also create folders implicitly, or run_command could be used). There are no exclusions, prerequisites, or context for selecting this tool among the many file-related siblings. 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.

• grepA
  3.8/5.0
  Behavior3/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. It correctly identifies the tool as read-only and specifies substring matching (from schema). However, it does not disclose case sensitivity, encoding, performance traits, or behavior when the file or pattern is not found.

  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?

  A single, front-loaded sentence of 10 words. Every word is meaningful; no fluff or redundancy. The structure is optimal for quick comprehension.

  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 simplicity (2 params, simple substring search, output schema exists), the description covers the essentials: what it does, what it returns (lines with numbers). It could mention error handling (e.g., file not found) but is still adequate for most use cases.

  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?

  Both parameters have full schema descriptions (100% coverage), so the description adds no new meaning beyond 'with line numbers' which is about output. Baseline 3 is appropriate since the schema already does the heavy lifting.

  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 action ('Return lines'), the resource ('matching pattern in a single file'), and includes output details ('with line numbers'). It distinguishes from siblings like read_file (returns whole file) and search_text (likely multi-file or different semantics).

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

  Usage Guidelines3/5

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

  The description implies usage for single-file substring search but provides no explicit guidance on when to use this tool versus alternatives (e.g., search_text, grep command in run_command). 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.

• write_fileA
  3.8/5.0
  Behavior3/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. It discloses that the file is created if missing and overwritten if present, which is key behavioral information. However, it does not mention whether permissions are checked, what happens if the parent path does not exist, or if there are size limits. With no annotations, some additional context would be helpful.

  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, concise sentence that front-loads the key action and behavior. Every word is necessary; there is no wasted text.

  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 simplicity (2 required params, no nested objects, output schema present), the description is nearly complete. It covers creation vs. overwrite behavior. The only minor gap is the lack of mention of error conditions (e.g., invalid path) or relationship to parent directories, which could be inferred but is not explicit.

  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 coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides for the two parameters. It restates that content is written but does not clarify file path format (absolute vs. relative) or content encoding beyond UTF-8, which is already in the description.

  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 verb ('Write'), the resource ('file'), and the encoding ('UTF-8'). It also specifies the behavior for missing vs. existing files, which distinguishes it from siblings like 'append_file' (which only appends) and 'replace_in_file' (which replaces specific text).

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives like 'append_file' or 'replace_in_file'. It implies use for creating or overwriting files, but provides no guidance on when to choose one sibling over another, nor does it mention prerequisites (e.g., parent directory must exist).

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

• glob_filesA
  3.9/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 clearly states that the tool returns paths recursively, which is a key behavioral trait. However, it does not disclose potential performance impact on large directory trees, response format details (sorted, absolute vs relative), or any limitations (e.g., hidden files, symlinks). Despite this, the essential behavior is well communicated.

  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?

  A single sentence with no wasted words. The essential information (return paths, glob pattern, recursive) is front-loaded and clear. Every word carries meaning.

  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 a simple tool with 1 parameter, 100% schema coverage, and an output schema present, the description is minimally complete. It does not specify return value semantics (e.g., what happens if no matches, absolute paths, sorted order) but the output schema likely handles details. It meets the basic bar for a list-tool with good schema 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 schema description coverage is 100% with a single parameter whose description gives an example pattern. The tool description adds only the word 'recursive' beyond what the schema provides. Baseline 3 is appropriate since schema already documents the parameter adequately and the description adds marginal value.

  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 uses a specific verb ('Return') and resource ('file paths matching a glob pattern'), and conveys an important behavioral trait ('recursive') that distinguishes it from sibling tools like 'list_dir', 'grep', and 'search_text'. It clearly indicates the tool's function of path pattern matching.

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

  Usage Guidelines3/5

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

  The description implies the tool is for pattern-based file discovery, but does not provide explicit guidance on when to use it versus siblings like 'list_dir', 'grep', or 'search_text'. No alternative tool mentions or exclusion criteria are given, so usage context is only inferred.

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

• get_cwdA
  4.3/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 full burden. It clearly states the tool returns the cwd and shows an example. However, it does not disclose whether the returned directory is absolute or relative, or whether symlinks are resolved. For such a simple tool, these are minor omissions.

  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 two short sentences plus one line example. Every part is necessary and there is no extraneous information.

  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 that the tool has no parameters, no annotations, but an output schema, the description is complete enough. It correctly describes the function, provides a usage example, and does not need to explain return values since the output schema exists.

  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 zero parameters and schema coverage is 100%, so the baseline with no param info is 4. The description confirms the zero-parameter requirement via the example, which aligns perfectly with 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 uses the specific verb 'Return' and clearly identifies the resource as 'the current working directory of the server process'. This is unambiguous and sufficiently distinct from sibling tools like list_dir, get_env_var, or tree, which have 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 includes a code example showing the function call with no arguments, which implies no special preconditions. However, no explicit guidance on when to use this vs. alternatives (especially similar tools like list_dir or get_env_var) is provided. The tool is simple enough that usage is obvious, but explicit exclusions would improve it.

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

• run_commandA
  4.3/5.0
  Behavior4/5

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

  Discloses the critical behavioral trait that it can run arbitrary commands and provides a caution. No annotations exist, so the description carries the full transparency burden and does so effectively. Lacks specifics about exit codes, timeout, or working directory.

  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?

  Three sentences, minimal waste, front-loaded with purpose, followed by important technical detail and a caution. Every sentence adds value.

  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 presence of an output schema (which handles return values) and simple schema, the description is mostly complete. However, a command execution tool would benefit from mentioning things like timeout behavior, environment variables, or potential side effects on the system.

  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 100% coverage with a clear parameter description. The description adds value by explaining the execution environment (cmd or sh) and supported features (pipes, redirects, chaining).

  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?

  Clearly defines the tool as executing a shell command and returning output. Distinct from siblings like 'python_code', 'grep', 'delete_folder', etc., which have narrower scopes.

  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?

  Explicitly notes the command runs through the platform shell and that pipes/redirects/chained commands work. Includes a caution about arbitrary commands. Could further clarify when to use this versus Python-specific tools like 'python_code'.

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