Server Quality Checklist

Tool Scores

• ssh_execB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavioral traits. It only states 'execute a command' without details on authentication, session handling, destructive potential, or output behavior, leaving significant gaps.

  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?

  Single sentence, no wasted words. However, it is extremely brief and lacks structure such as front-loading key terms, though it remains concise.

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

  Completeness2/5

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

  For a remote execution tool, the description lacks important context like shell environment, return values, error behavior, and prerequisites. Despite simple parameters, more completeness is needed for effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema documents both parameters. The description adds no additional meaning beyond the schema; it merely restates the tool's purpose without enriching parameter context.

  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 'Execute a command on a remote server' clearly states the action (execute) and resource (command on a remote server). It distinctly differs from sibling tools like ssh_download, ssh_upload, etc., which perform different operations.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives, when not to use it, or prerequisites. The sibling tool names provide some context, but the description itself lacks explicit usage direction.

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

• ssh_listB
  3.1/5.0
  Behavior2/5

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

  No annotations are available, so the description must fully disclose behavior. It only says 'list files' without detailing how directories are traversed, whether hidden files are included, or error handling for nonexistent paths.

  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 clear sentence with no redundancy. It could be improved by adding a brief example or mentioning the output format, but it is concise and front-loaded.

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

  Completeness2/5

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

  Given the tool's moderate complexity (SSH interaction) and lack of output schema or annotations, the description is incomplete. It omits details like whether it returns full paths or just names, and does not mention security or configuration requirements.

  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 schema already defines the parameters. The description adds no new context beyond what the schema provides (e.g., default path, server alias). 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 verb 'List' and the resource 'files in a remote directory', which distinguishes it from sibling tools like ssh_download (downloads files) and ssh_exec (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 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 ssh_download or ssh_exec. The description does not mention prerequisites like SSH setup or when listing is appropriate.

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

• ssh_downloadA
  3.8/5.0
  Behavior3/5

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

  Annotations are absent, so description carries full burden. It mentions SFTP and recursion behavior, but omits details on permissions, overwrite behavior, error handling, or authentication requirements. Basic behavioral info is present but incomplete.

  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?

  A single 33-word sentence is concise and front-loaded with the action. Could be structured with bullet points for easier scanning, but remains effective and lacks fluff.

  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?

  No output schema exists, yet description does not mention return values, success indicators, or error scenarios. Lacks completeness on outcomes and prerequisites (e.g., authentication, storage space). Covers main mechanics but leaves gaps.

  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 descriptions. Tool description adds value by explaining parameter interactions: remotePath supports globs, recursive flag required for directories, and localPath as destination. This goes beyond schema definitions.

  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 'Download from a remote server over SFTP', identifies the action and protocol. It specifies supported patterns (single file, glob, recursive directory), distinguishing it from sibling tools like ssh_upload.

  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 (e.g., ssh_upload, ssh_exec). No guidance on prerequisites or conditions for use, leaving the agent to infer from context.

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

• ssh_list_serversA
  3.8/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 discloses the action (listing) but does not mention any side effects, prerequisites (e.g., SSH agent), or behavior like sorting or pagination. For a simple read tool, this is adequate but not thorough.

  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?

  Single sentence with zero waste. Front-loaded with the core action and result. Ideal conciseness 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 the tool's simplicity (no parameters, no output schema), the description is mostly complete. It could optionally mention that the descriptions come from SSH config files, but not required.

  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?

  Tool has no parameters, so baseline 4 applies. Description adds no parameter info, but none is needed as the schema already covers everything.

  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 explicitly states the tool lists all configured server aliases and their descriptions, using a specific verb and resource. It distinguishes from sibling tools like ssh_exec or ssh_download by focusing on configuration listing.

  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 on when to use this tool versus siblings like ssh_list or alternatives. The description provides no context for appropriate usage or exclusions.

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

• ssh_uploadA
  4/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 mentions SFTP and modes but omits critical details like overwrite behavior, authentication requirements, error handling, or file permissions. This gap leaves the agent unaware of potential side effects.

  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 with zero waste. The first sentence clearly states the core action, and the second efficiently lists the supported modes and parameters. Front-loaded and easy to parse.

  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 file upload tool with 5 parameters, the description covers the main usage patterns (file, glob, directory) and the relevant parameter (preserve). It lacks details on return values (not needed without output schema) and error scenarios, but overall provides sufficient guidance for typical use.

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

  Parameters4/5

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

  Schema coverage is 100%, baseline 3. The description adds meaning beyond the schema by explaining how glob patterns upload matches into remotePath, that recursive=true is required for directories, and what the preserve parameter does (preserve mode/timestamps). This enhances 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 verb 'Upload' and the resource 'remote server over SFTP'. It distinguishes itself from siblings like ssh_download (download), ssh_exec (execute commands), ssh_list (list files), and ssh_list_servers (list servers) by focusing on uploads.

  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 specifies when to use the tool (for uploads) and details three modes: single file, glob pattern, and directory with recursive=true. It implies usage context but lacks explicit exclusions or alternative tool suggestions (e.g., 'Use ssh_download to retrieve files').

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