Server Quality Checklist

Tool Scores

• zip_createA
  3.9/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 transparency burden. It discloses the underlying implementation (PowerShell Compress-Archive), wildcard support, and the .zip extension requirement. However, it omits critical behaviors like what happens if the destination exists (overwrite?), error handling, or whether folder structure is preserved. The disclosed details help but are incomplete.

  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 concise: two sentences that front-load the main action and follow with usage context. It includes only essential information without fluff, making it easy to scan.

  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 two-parameter tool with no output schema, the description covers the main purpose and usage. However, it does not explain important edge cases like overwrite behavior, directory recursion, or potential side effects. Given the lack of annotations, the description should provide a bit more context to be fully complete.

  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 has 100% coverage with descriptions and examples for both source and destination. The description adds a note about wildcards and the .zip extension, but these are already mentioned in the schema examples. The description does not add significant extra meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb+resource: 'Create a ZIP archive from files or folders.' It distinguishes from sibling tools like zip_extract by focusing on compression/creation rather than extraction. The use cases (backup, sharing, archiving) reinforce the purpose.

  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?

  It explicitly says 'Use this tool to compress files/folders into a .zip file for backup, sharing, or archiving', providing clear context for when to use it. It does not explicitly mention when not to use it or name alternatives, but the distinction from zip_extract is obvious. Wildcard and destination extension guidance are also given.

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

• zip_extractA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the destination folder is created automatically and that it uses PowerShell Expand-Archive. However, it does not mention overwrite behavior, error handling, or return value, which are relevant gaps for an extraction tool. This adds some transparency but is not comprehensive.

  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 three sentences: one for the action/verb, one for usage guidance, and one for a behavioral side-effect. Every sentence earns its place, and there is no redundant or filler language. It is concise and well-structured.

  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 (2 parameters, no output schema), and the description covers the core purpose, usage, and a key side-effect. It does not mention overwrite behavior or password-protected archives, but these are edge cases for a basic extraction tool. Overall, it is sufficiently complete for an agent to invoke the tool correctly.

  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 covers both parameters with clear descriptions (archive path and destination folder), so the baseline is 3. The description does not add additional meaning about the parameters themselves; the auto-create note is more about destination folder behavior than parameter semantics. Thus, it stays at baseline.

  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: 'Extract a ZIP archive to a destination folder using PowerShell Expand-Archive.' This is a specific verb+resource+destination, and it distinguishes the tool from siblings like zip_create. The phrase 'Use this tool to unzip archives' reinforces the purpose without ambiguity.

  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?

  It explicitly says 'Use this tool to unzip archives,' which provides a clear when-to-use instruction. However, it does not mention alternatives or when-not-to-use, though the sibling context (e.g., zip_create) makes the distinction implicit. This is clear context but lacks explicit exclusions, so it gets a 4 rather than a 5.

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

• file_readA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description discloses relevant behavioral traits: files are read in text mode with UTF-8 default, path must be absolute, and only text-based files are supported. This goes beyond the schema by stating the read mode and platform context, though it does not cover error behavior or large file handling.

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

  Conciseness4/5

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

  The description is front-loaded with the primary action in the first sentence, followed by concise usage examples, encoding behavior, and constraints. The list of file extensions is useful but lengthens the description slightly. Overall, each sentence 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 simple read tool with 2 params and no output schema, the description covers purpose, usage, constraints, and return value (full text). It could mention error cases or limits, but for this level of complexity it is reasonably complete.

  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 both parameters have descriptions. The description repeats the absolute path requirement and UTF-8 default already in the schema. It adds the list of supported file extensions, which provides context for the path parameter, but does not materially enhance parameter understanding.

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

  Purpose5/5

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

  The description clearly states the tool reads and returns full text contents of a file, with a specific verb ('Read') and resource ('file contents'). It enumerates supported file types and differentiates from siblings like file_write and file_search by focusing on reading existing text files.

  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 provides explicit context for when to use the tool ('view configuration files, read source code, inspect log files, or extract data from files') and an explicit exclusion ('For binary files... use a different approach'). It does not name specific alternative tools but gives clear conditional guidance.

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

• dir_listA
  4.2/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 of behavioral disclosure. It reveals key traits: default path behavior ('lists the user's home directory'), recursive mode depth (up to 3 levels), and the type of information shown (names, type, size, date). While it doesn't cover error handling or permissions, it does communicate the core behaviors adequately.

  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 three sentences: first states the core action and output, second explains recursive behavior, third gives use cases and default path. It is front-loaded with the most important information and contains no extraneous wording.

  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 no output schema, but the description covers purpose, behavior, default, and recursion limit. It might benefit from mentioning error behavior or whether hidden files are shown, but for a straightforward listing tool it is sufficiently complete for an agent to invoke correctly.

  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 already provides 100% coverage of parameters with descriptions for 'path' and 'recursive' (including defaults and max depth). The description mainly echoes these details ('If no path is provided, lists the user's home directory') without adding new semantics, so it meets the baseline but doesn't exceed it.

  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's function: 'List the contents of a folder/directory on this Windows PC.' It specifies the output (file names, type, size, modified date) and distinguishes itself from sibling tools like file_search by focusing on directory listing rather than search.

  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 provides clear use cases: 'Use this to explore folder structures, locate files, check file sizes, or inspect directory contents.' It offers context for when to use the tool but does not explicitly mention alternatives or when not to use it, so it misses the exclusions needed for a 5.

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

• notifyA
  4.2/5.0
  Behavior4/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 adds useful context: the notification stays visible for ~6 seconds and displays without opening a window. However, it does not mention return behavior, error handling, or potential blocking, which would be helpful for a complete picture.

  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 concise and well-structured: the first sentence states the purpose, the second gives usage context, and the third notes the duration. Every sentence earns its place, with no filler or redundancy.

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

  Completeness4/5

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

  For a simple two-parameter notification tool, the description covers purpose, usage, and a key behavioral trait (duration). There is no output schema, so a brief mention of return behavior (e.g., immediate success or void) would improve completeness, but the current level is 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?

  Schema coverage is 100%, and the schema already provides descriptions and examples for both parameters (title and message). The description only says "given title and message" without adding further semantic context, so it does not add value beyond the schema. Baseline 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 clearly states the tool's function with a specific verb and resource: "Show a Windows notification balloon with the given title and message." This is distinct from sibling tools, none of which involve notifications, so there is no ambiguity about what the tool does.

  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 provides explicit when-to-use guidance: "Use this tool to notify the user when a long task finishes, when something needs their attention, or to display information without opening a window." It does not mention when-not-to-use or alternative tools, but the use cases are clearly enumerated, making this a strong guideline.

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

• run_commandA
  4.2/5.0
  Behavior4/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 default shell (PowerShell), default timeout (30 seconds), return of both STDOUT and STDERR, and a clear warning that dangerous commands execute. This goes beyond basic expectations and informs the agent about important constraints. It does not cover details like exit codes or failure behavior, but the description's warning is a notable transparency benefit.

  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 concise and front-loaded with the main action. It uses a short list of use cases and a warning, all within four sentences. Every sentence contributes valuable information without redundancy. The structure is clear, with the warning placed at the end for emphasis.

  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 4 parameters, no annotations, and no output schema, the description covers the core operational details: shells, timeout, stdout/stderr, and safety warning. The main gap is not referencing the sibling run_command_long, which is directly relevant for extended timeouts. Despite this, the description is sufficiently complete for an agent to select and use the tool correctly for the majority of 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?

  The input schema already provides descriptions for all parameters (100% coverage), including examples and defaults. The description adds minimal extra meaning beyond the schema, mainly emphasizing that shell can switch to Git Bash/WSL for Unix commands and that the timeout is configurable. This is helpful but does not significantly elevate above the schema baseline, so a 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 clearly states the tool executes a shell command on the local Windows PC and returns output. It lists specific use cases (npm, pip, git, network diagnostics) and explicitly differentiates from other sibling tools like file_read or sys_info. The purpose is unambiguous and uses a specific verb+resource construction.

  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 provides strong context for when to use the tool: 'Use this tool to run any CLI command' with examples. It also gives clear shell selection guidance ('Use PowerShell unless the command is Unix-specific' is in the schema, but description reinforces it). However, it does not explicitly mention alternative tools like run_command_long or state when to prefer them, so exclusions and alternatives are partially covered.

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

• screen_captureA
  4.2/5.0
  Behavior4/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 details that the screenshot is captured using .NET System.Drawing from the primary monitor at full resolution, and that it returns PNG base64 data. This is thorough, though it does not mention potential failure modes or permission requirements, which are not critical for a screenshot tool.

  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 well-structured, starting with the core action, then return format, use cases, and technical details. It is somewhat lengthy due to the enumeration of use cases, but each sentence provides value. It is appropriately front-loaded with the most important 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?

  For a tool with one optional parameter and no output schema, the description fully covers the essential context: what it does, how it returns the image, technical background, and the optional save behavior. It leaves no gaps regarding the tool's basic operation and integration with the AI.

  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 only parameter, output_path, is fully described in the schema: 'Absolute path to save the screenshot PNG file to disk. If omitted, the screenshot is still captured and returned as base64 image data but not saved to a specific file location.' The description repeats this with 'Optionally save the screenshot to a specific file path on disk' but adds no new meaning beyond the schema, so the 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 clearly states the tool's function with a specific verb and resource: 'Capture a screenshot (screen grab) of the primary monitor on this Windows PC.' This is unambiguous and distinguishable from any sibling tools, which are all unrelated to screenshots.

  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 provides a clear list of use cases: 'see what's currently displayed on screen, debug UI issues in applications, verify visual changes, create visual documentation, or monitor what's showing on the display.' It gives context for when to use the tool but does not explicitly state when not to use it or mention alternatives, which are not needed given the absence of similar tools.

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

• clipboard_setA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It explains the core behavior (sets clipboard for immediate paste), the platform (Windows), and the temporary nature of the clipboard. It does not explicitly state that existing clipboard content is overwritten, but that is inherent to 'copy to clipboard.' The description adds adequate behavioral context for a simple 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 three sentences, front-loaded with the main action, and every sentence earns its place: action, context, use cases, and parameter requirement. No fluff or redundancy.

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

  Completeness5/5

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

  For a simple one-parameter tool with no output schema, the description fully covers what the agent needs: purpose, usage scenarios, parameter requirement, and platform. It is complete within its 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%, and the schema already documents the 'text' parameter with an example. The description merely repeats that the parameter is required without adding new semantic detail, so the baseline 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+resource ('Copy text to the Windows system clipboard') and clearly distinguishes from siblings like clipboard_get by focusing on the set operation. It also lists concrete use cases, making the tool's purpose unmistakable.

  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 provides clear usage context ('copy command output', 'transfer text between applications', 'automate copy-paste workflows') but does not explicitly mention when not to use it or contrast with the sibling clipboard_get. This is clear context without exclusions, matching a 4.

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

• file_searchA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of transparency. It discloses key behaviors: recursive search, use of PowerShell Get-ChildItem, and output of absolute paths. It does not mention edge cases like hidden files or search limits, but the core behavioral traits are covered.

  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 four sentences, front-loaded with the main action, includes concrete pattern examples, and ends with output expectations. Every sentence adds value with no fluff or redundancy.

  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?

  The tool is relatively simple with 3 parameters (1 required), full schema coverage, and a description that covers purpose, use cases, behavior, and return format ('absolute path of each matching file'). No output schema is present, but the description provides sufficient context for an agent to select and invoke correctly.

  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 examples for pattern, directory, and max_results. The description does not add new parameter-specific information beyond reinforcing the glob pattern concept. Baseline 3 is appropriate because the schema 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?

  Description clearly states the tool's purpose: 'Search for files on this Windows PC by name pattern (glob/wildcard).' It specifies the resource (files) and verb (search), and distinguishes from siblings like dir_list (which lists directory contents) by emphasizing recursive 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 Guidelines4/5

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

  The description provides clear use cases: 'find misplaced files, locate all files with a specific extension, discover configuration files, or audit files in a directory.' It does not explicitly name alternatives or when-not-to-use, but the context is unambiguous enough for an agent to decide when to invoke this tool.

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

• open_pathA
  4.3/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 transparency burden. It discloses the underlying mechanism ('Uses Windows Start-Process under the hood') and details what happens for each input type (registered app, Explorer, web browser). It does not discuss error behavior or whether the call blocks, but for a simple open operation, this is adequate.

  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 concise and efficiently structured: an overview sentence, a breakdown by target type, and a use-case sentence. There is no fluff, and every sentence contributes meaningful 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?

  For a simple tool with one parameter, no output schema, and no annotations, the description covers the purpose, target types, use cases, and implementation detail. It is fully sufficient for an agent to understand when and how to invoke it.

  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 describes the single parameter 'target' in detail with examples, so schema coverage is 100%. The description doesn't add new syntactic or format details for the parameter itself, but it does clarify behavior based on target type. Per the rubric, when schema coverage is high, a baseline 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 opens with a clear, specific verb+resource: 'Open a file, folder, or URL using the default application on this Windows PC.' It then breaks down behavior for each target type, which distinctly positions it against siblings like file_read (which reads content) and run_command (which executes commands).

  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 explicitly enumerates when to use the tool: 'Use this to open documents, launch applications via file shortcuts, browse folders in Explorer, or open websites in the browser.' It provides clear context but does not explicitly name alternatives or exclusionary conditions, so it misses the top score.

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

• process_listA
  4.3/5.0
  Behavior4/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 reveals the output fields, the top 30 limit, filtering behavior (partial match, case-insensitive), and sortable options. It doesn't mention permissions or potential errors, but for a read-only listing tool this is sufficient context.

  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 exceptionally concise and well-structured. It opens with the core purpose, then lists output fields, filtering, sorting, the 30-item limit, and closes with use cases. Every sentence adds value; no filler or redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity, the description is complete. It explains what the tool does, what data it returns, how to narrow results, and why you'd use it. No output schema exists, but the description covers the return content. It's fully adequate for an AI agent to select and invoke it correctly.

  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 baseline is 3. The description restates filtering and sorting but adds little beyond the schema's own detailed parameter descriptions (including examples and default sort in the schema). The phrasing 'find RAM hogs' and 'find CPU hogs' adds usage intent but not new parameter semantics.

  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 starts with a clear verb and resource: 'Display a list of processes/applications currently running on this Windows PC.' It specifies the output fields (process name, PID, memory, CPU time) and distinguishes itself from siblings like process_kill by focusing on listing and inspection.

  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 states useful scenarios: 'monitoring, debugging, finding resource-consuming processes, or identifying processes before killing them.' This implies when to use it, and the reference to 'before killing them' indirectly points to the sibling tool process_kill. It doesn't explicitly name alternatives or exclusions, but the context is clear.

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

• sys_infoA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral transparency. It lists the data returned and uses the verb 'retrieve', implying read-only, but it does not explicitly state that the tool is non-destructive or whether any permissions are needed. This is a minor gap for a diagnostic tool.

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

  Conciseness5/5

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

  The description is a single well-structured paragraph: an opening purpose statement, an enumerated list of returned information, and a closing use-case sentence. Every sentence earns its place; no filler.

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

  Completeness5/5

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

  Despite having no output schema, the description enumerates all key result categories (system, CPU, RAM, storage, network), which gives the agent a clear expectation of the return value. Combined with the explicit use cases, the description is fully complete for this parameterless tool.

  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, so the description need not explain any. According to the calibration guide, the baseline is 4; the description correctly focuses on the tool's output instead.

  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 'retrieve' with the resource 'detailed and comprehensive system information about this Windows PC', and then enumerates the exact categories (hostname, OS version, uptime, CPU, RAM, disk, network). This clearly differentiates from sibling tools like process_list and run_command.

  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 explicitly states it is 'useful for diagnostics, resource monitoring, checking PC specifications, or troubleshooting system issues', giving clear context for when to invoke. It does not explicitly mention alternatives, but the sibling tools are sufficiently different that no exclusion is needed.

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

• file_writeA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and it does so thoroughly: it explains automatic file/directory creation, full overwrite of existing content, requirement for absolute path, and UTF-8 encoding. These are exactly the behavioral traits that matter for a write operation and are not present in any structured fields.

  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 concise and well-structured: main action first, then behavior, then use cases, then constraints. Every sentence adds value without redundancy. It is neither overlong nor terse, and the front-loading makes it easy for an agent to grasp the core purpose immediately.

  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 (two string parameters, no output schema), and the description covers the essential operational details: path requirements, overwrite behavior, auto-creation, encoding, and use cases. It does not mention what the tool returns on success or failure, but that is a minor gap for a write operation; an agent can still invoke it correctly based on available information.

  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 already documents both parameters completely (100% coverage), including examples and the auto-create directory behavior in the path description. The tool description adds the UTF-8 encoding detail, which is a useful extra, but it does not significantly enrich parameter meaning beyond the schema. The baseline of 3 applies because the schema carries the load.

  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 opens with a clear, specific action: 'Write text content to a file on this Windows PC.' It then lists concrete use cases (create config files, save processed data, write source code, generate scripts) that distinguish it from sibling tools like file_read, dir_list, and file_search. The verb+resource+scope is precise and non-tautological.

  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 provides explicit use cases ('Use this to create new configuration files, save processed data output, write source code...') and states the overwrite behavior, which implies when it is appropriate. It does not explicitly name alternatives or say 'do not use when only appending', but the context is clear enough for an agent to decide between write and other file operations.

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

• run_command_longA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the command runs through PowerShell.exe, has a default 2-minute timeout, a larger output buffer, and returns STDOUT, STDERR, and exit code. However, it does not mention what happens when the timeout is exceeded or potential side effects of executing arbitrary shell commands.

  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, each serving a distinct purpose: purpose statement, usage guidance with examples and sibling distinction, and behavioral details. The description is front-loaded and every sentence earns its place; there is no 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 command-execution tool with a rich schema, the description covers purpose, usage scenarios, behavioral traits, and return information. It lacks details about timeout failure behavior and potential risks, but is otherwise complete enough for an agent to understand when and how to invoke the tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds context around the timeout parameter by explaining the default and the 'larger output buffer' behavior, but the schema already provides detailed descriptions and examples for each parameter. The description adds limited extra meaning beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific verb-resource pair: 'Execute a long-running shell command on this Windows PC and return all output after completion.' It clearly states what the tool does and explicitly distinguishes itself from the sibling tool run_command by noting the longer default timeout and intended use cases.

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

  Usage Guidelines5/5

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

  The description explicitly contrasts with run_command and lists concrete scenarios where this tool is appropriate: npm install, pip install, compiling projects, downloading large files, building projects, git clone, running test suites, and backup processes. This provides clear when-to-use guidance and implies run_command is for shorter commands.

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

• clipboard_getA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It clearly implies a non-destructive read, explains the clipboard concept, and explicitly states the empty-clipboard return value. It does not mention error conditions or non-text formats, but these are minor gaps for a simple getter.

  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 three sentences with the main action in the first sentence, followed by useful context and the return behavior. Every sentence contributes information, and there is no verbosity.

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

  Completeness5/5

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

  For a parameterless, synchronous read tool, the description fully covers what it does, why it is useful, and what it returns when empty. No output schema exists, but the description provides sufficient return-value expectations.

  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, so there is nothing for the description to clarify. Per the baseline for parameterless tools, the description adds sufficient value without needing parameter detail.

  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 opens with a specific verb and resource: 'Read the current text content of the Windows system clipboard'. This clearly distinguishes it from sibling clipboard_set and 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 Guidelines4/5

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

  The description provides clear context for when to use the tool: 'useful to grab data copied from other applications or verify what was last copied'. It stops short of explicitly naming exclusions or comparing with alternatives, but the use cases are evident.

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

• key_typeA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that it uses SendKeys, that text is escaped automatically, that keys are raw, and that input goes to the focused window. It also mentions the delay_ms behavior. However, it doesn't mention potential side effects (e.g., typing into an unexpected window if focus is lost) or error conditions, which would make a 5.

  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 compact paragraph front-loaded with the core purpose, followed by the prerequisite, then the two modes with examples. Every sentence adds value: purpose, focus guidance, text mode, keys mode, and a sample usage. No wasted words.

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

  Completeness4/5

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

  Given the tool's complexity (three params, no annotations, no output schema), the description covers the essential usage, examples, and a prerequisite. It's missing some edge-case details (e.g., behavior if no window is focused, how special characters are escaped) but still provides enough for an agent to invoke it correctly. A 5 would require more on failure modes or return behavior.

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

  Parameters5/5

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

  Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning: it explains the precedence of 'keys' over 'text', provides concrete examples for both parameters, and gives guidance on delay_ms values (50-100 for stable typing). This goes well beyond the schema descriptions.

  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 types text or sends keystrokes to the focused window using PowerShell SendKeys. It uses a specific verb ('type'/'send'), names the resource ('currently focused window'), and distinguishes itself from sibling tools like run_command and clipboard_set by focusing on keyboard input.

  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 gives an explicit prerequisite: 'Call window_focus first to make sure the target window is active.' It also explains when to use 'text' vs 'keys' with examples. However, it doesn't explicitly mention when NOT to use this tool or name alternatives (e.g., using clipboard_set for large text), so it falls short of a 5.

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

• process_killA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses destructive behavior: 'force-killed without confirmation,' 'killed processes cannot be recovered,' and 'unsaved data will be lost.' It also clarifies that name targeting kills ALL instances, which is critical operational context.

  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 compact: three sentences front-loaded with the action, followed by targeted use cases and a warning. No filler or redundancy; every sentence contributes essential 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?

  For a destructive tool with no annotations or output schema, the description covers the action, targeting options, consequences, and use cases. It is sufficiently complete for an agent to invoke the tool correctly and assess risks.

  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 detailed parameter descriptions: pid is described as safer since it kills one process, and name kills all instances. The tool description repeats these points but doesn't add new parameter-specific semantics, so baseline 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 'Force-terminate a running process on this Windows PC' with a specific verb and resource. It distinguishes between targeting by name (kills all instances) and by PID (kills specific process), which also differentiates it from sibling tools like process_list.

  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 provides explicit use cases: 'stop hung/frozen applications, close unwanted programs, or free up blocked resources.' It does not mention alternatives or exclusions, but no direct sibling tool competes with this kill functionality, so the guidance is clear enough.

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

• window_focusA
  4.5/5.0
  Behavior4/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 case-insensitive matching, substring matching (title contains text), and error behavior when no matching window is found. This is strong behavioral detail, though it does not mention behaviors like minimizing or restoring windows if minimized.

  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 three sentences long, front-loaded with the core action, followed by usage guidance, examples, and error behavior. Every sentence serves a purpose without redundancy.

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

  Completeness5/5

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

  For a tool with one parameter and no output schema, the description is complete. It covers what the tool does, when to use it, matching behavior, and error handling, all in a compact form. No critical information is missing given the tool's simplicity.

  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 covers 100% of parameters, but the description adds value by explaining the matching semantics (case-insensitive, contains text) and giving examples. This enriches the parameter meaning beyond the schema's 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 tool's function with a specific verb ('Bring a window to the foreground') and resource ('window'), and distinguishes it from sibling tools by focusing on window focus, which is unique among the provided siblings. The method (matching title or process name) is also explicitly mentioned.

  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?

  It says to use the tool 'before sending keys or interacting with it,' which provides clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the guidance is sufficient given the sibling set, and it implies a workflow with key_type.

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