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

No annotations are provided, so the description must carry the full burden. It discloses the destructive nature of deleting but omits critical behavioral details such as irreversibility, error behavior for nonexistent files, permission requirements, or whether directories are supported.

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

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

The description is a single concise sentence with no filler. It is appropriately sized for a simple delete operation and front-loaded with the action and resource.

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

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 and no output schema, the description is too sparse. It fails to mention side effects, whether deletion is recursive or permanent, and how the system handles missing files. The schema covers parameters, but behavioral context is lacking.

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

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

Schema coverage is 100% (both sessionId and remotePath have descriptions), so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, making it adequate but not enhancing.

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

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

The description clearly states the tool deletes a file on a remote system, using the specific verb 'Delete' and identifying the resource. This distinguishes it from sibling tools like sftp_upload, sftp_download, and sftp_list.

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

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

The description implies when to use the tool (when a file needs deletion) but provides no explicit guidance about prerequisites, alternatives, or exclusions. It does not mention that a valid session is required or that this tool is for files only, not directories.

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

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 does not disclose whether the download overwrites an existing local file, whether it requires an existing SFTP session, or the format of the result. This is a minimal behavioral disclosure.

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

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

The description is a single concise sentence with no redundant words. It is appropriately front-loaded and easy to parse.

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

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

For a simple tool with fully described parameters, the description is minimally adequate but missing key contextual aspects such as return value expectations and behavioral constraints. It does not mention what the tool returns or potential side effects, leaving some gaps.

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

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

Schema description coverage is 100% (all three parameters have descriptions). The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Download' and the resource 'a file from remote system via SFTP', making the primary purpose obvious. It naturally distinguishes from sibling tools like sftp_upload, though it does not explicitly reference alternatives.

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

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 sftp_upload or sftp_list. The description simply states the action without any context about prerequisites (e.g., active session) or scenarios.

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

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 only states the action, but does not mention that an active SFTP session is required, what the output format is (e.g., array of names), or how errors are handled. This leaves significant behavioral aspects undisclosed.

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

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

The description is a single concise sentence with no unnecessary words. It is front-loaded with the core action and resource, making it easy to parse.

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

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

The tool has no output schema, so the description should explain what the return value is. It only says 'List contents' without specifying whether the result is a list of names, includes file sizes, or handles hidden files. Additionally, no usage context or session requirements are mentioned, leaving the description incomplete for an AI agent.

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

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

The input schema already provides 100% description coverage for both parameters (sessionId and remotePath). The description adds no additional parameter-level meaning beyond what the schema states, 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.

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

The description uses a specific verb 'List' and resource 'remote directory', clearly stating the tool's function. It distinguishes itself from sibling tools like sftp_upload, sftp_download, and sftp_delete, 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.

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, nor any prerequisites or context. While siblings are different operations, there is no explicit mention of when listing is appropriate, such as before downloading or after connecting.

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

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

Since no annotations are provided, the description carries the full burden of disclosure. It only states the action without mentioning side effects, overwrite behavior, or the need for an active connection, leaving behavioral traits unspecified.

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

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

The description is a single, succinct sentence that conveys the core action without extraneous detail, achieving high clarity in very few words.

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

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

For a tool with no output schema and no annotations, the description is too sparse to be fully contextual. It omits critical context such as whether the session must already be connected, overwrite semantics, and error conditions, making it inadequate for an agent to correctly invoke the tool in all scenarios.

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

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

The input schema already provides descriptions for all three parameters (100% coverage), so the description adds no additional semantic nuance beyond the schema. The parameter descriptions are minimal but sufficient for identifying each field.

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

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

The description uses a specific verb ('Upload') and resource ('a file to remote system') with the method (via SFTP), clearly distinguishing it from sibling tools like sftp_download, sftp_list, and sftp_delete.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites such as an active session or which sibling tools handle other operations like downloading or listing files.

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

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 only states the action without mentioning side effects (e.g., whether the SSH session remains open), reversibility, or any prerequisites. This is a significant gap for a mutating operation.

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

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

The description is one concise sentence with no extraneous words. Every word earns its place, and it is appropriately sized for a simple operation.

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

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 no output schema, the description is nearly complete. It tells the agent what the tool does, and the schema covers the input. The only deficiency is the lack of behavioral context, but given the simplicity, this is not critical.

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

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

The input schema already provides 100% coverage of the single parameter 'forwardId' with a description. The tool description adds no additional meaning beyond the schema, 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.

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

The description 'Close an SSH tunnel' clearly states the action and resource. However, it could be more specific by using 'port forward' instead of 'tunnel', especially to differentiate from ssh_disconnect which likely closes an SSH session. Still, the verb 'close' and resource are clear.

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

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

The description implies usage as the counterpart to ssh_port_forward, but provides no explicit guidance on when to use it or exclude alternatives. It is a minimal operation with no other close tool, so the intent is understood but not elaborated.

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

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. 'Establish' is vague about what actually happens—whether it opens an interactive session, tests connectivity, persists the connection, or requires a subsequent disconnect. It does not mention session lifecycle or side effects like ControlMaster multiplexing.

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

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

The description is a single, concise sentence with no wasted words. It lacks structured detail but is appropriately sized for a simple tool statement, earning a high score for efficiency.

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

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

With no annotations, no output schema, and five parameters, the description is severely incomplete. It fails to explain the return value, session persistence, how to disconnect, or the purpose of useControlMaster. For a tool that likely serves as a prerequisite for other SSH operations, far more context is needed.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no additional meaning about parameters 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.

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

The description 'Establish an SSH connection to a remote host' uses a specific verb ('Establish') and resource ('SSH connection'), clearly indicating the tool's function. It does not explicitly differentiate from sibling tools like ssh_execute or sftp_upload, but the resource name 'connection' makes it reasonably distinct.

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

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

The description provides no guidance on when to use this tool versus alternatives like ssh_execute or sftp_upload. There is no mention of prerequisites, follow-up commands, or scenarios where this tool is preferred, leaving usage purely implied by the name.

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

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 only restates the action ('Close an SSH connection') without detailing side effects, reversibility, error conditions, or whether the session is immediately terminated. This is essentially a tautology when compared to the tool name 'ssh_disconnect'.

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

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

The description is a single, short sentence that contains no unnecessary words. It is extremely concise and front-loaded, making it easy to parse.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description minimally covers the action. However, it lacks usage context, behavioral nuances, and alternative differentiations, leaving the agent to infer too much. It is adequate but not complete.

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

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

The input schema already provides 100% coverage with a clear description of 'sessionId' ('Session ID to disconnect'). The tool description adds no further parameter meaning, 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.

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

The description uses a specific verb ('Close') and resource ('SSH connection'), clearly distinguishing this from siblings like ssh_connect (which opens a connection) and ssh_close_forward (which closes a port forward). It is concise and unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or when not to use it. The only usage cue is the tool's name and the intuitive action, but that is not sufficient for an agent to select it confidently among many ssh-related tools.

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

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 only states the core function without revealing potential side effects, session requirements, timeout behavior, or output format. For a tool that can execute arbitrary commands, this is a significant transparency gap.

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

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

The description is a single sentence with no filler words, making it concise and front-loaded. However, it is so brief that it borders on under-specification, which slightly reduces its effectiveness.

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

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

The tool lacks both annotations and an output schema, and the description only covers the basic action. It fails to mention prerequisites (session management), the tool's place among sibling tools, or the potential impact of executing commands, making it incomplete for safe and correct use.

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

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

The input schema has 100% parameter description coverage, so the baseline is 3. The description itself adds no additional parameter semantics beyond what the schema already provides, but it doesn't need to compensate.

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

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

The description clearly states the action ('Execute a command') and target ('remote system via SSH'), which distinguishes it from sibling tools like ssh_connect or sftp_upload. However, it doesn't explicitly mention that it requires an existing session, which is a key aspect of its purpose.

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

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, nor does it mention prerequisites like establishing a session with ssh_connect first. It also doesn't clarify that this is for running commands rather than transferring files, which is implied but not stated.

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

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 only states the action without disclosing output format (e.g., MD5/SHA256), whether it reads from a local file, or error behavior. This is insufficient for a tool with zero annotation support.

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

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

The description is a single sentence with no filler words, efficiently stating the core purpose. It is front-loaded with the verb and object. However, the extreme brevity contributes to missing behavioral details, though that is a completeness concern rather than a conciseness issue.

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

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

With no annotations and no output schema, this description is too sparse to be fully actionable. It lacks information about return values, fingerprint algorithm, and any side effects (e.g., does it rely on local ssh-keygen?). A more complete description would mention output type or usage parameters.

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

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

The input schema already describes keyPath as 'Path to key file' with 100% coverage. The description adds no further meaning about the parameter, such as format or constraints. Since schema does the heavy lifting, baseline 3 is appropriate.

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

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

The description 'Get fingerprint of an SSH key' uses a specific verb ('Get') and clearly identifies the resource ('fingerprint of an SSH key'). It distinguishes itself from siblings like ssh_keygen (generates keys) and ssh_list_keys (lists keys) by focusing solely on fingerprint retrieval.

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

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 or any alternatives. There is no mention of prerequisites (e.g., key must exist) or typical scenarios. For a tool with no explicit alternatives, some context about intended use is still expected.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It implies a read-only operation but does not explicitly state side effects, permissions, or the format of the returned data. Given it's a getter, some transparency is expected, but the description provides minimal information beyond the tool's name.

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

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

The description is a single short sentence, which is efficient and easy to parse. It avoids unnecessary detail. However, it is so terse that it borders on under-specification, but for a simple tool this level of conciseness is acceptable.

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

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

Given the tool has no output schema and no annotations, the description should clarify what the returned configuration looks like or any important edge cases. It does not. The tool is simple, but the description is insufficient for an agent to fully understand the tool's behavior or response format.

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

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

The schema already documents the only parameter 'hostname' with a description, achieving 100% schema coverage. The description adds little beyond the schema, merely referencing 'host' in the text. Since the baseline is 3 for high schema coverage, this is a reasonable score.

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

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

The description clearly states the action ('Get') and the resource ('SSH configuration' for a host). It distinguishes from sibling tools like ssh_connect or ssh_execute by focusing on configuration retrieval. However, it does not specify what 'configuration' includes (e.g., hostname, port, user), leaving some ambiguity.

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

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. There is no mention of prerequisites, such as whether a host must be defined in an SSH config file, or when it would be more appropriate than ssh_connect. The description simply states what it does.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It only states the action 'generate' but doesn't mention side effects like overwriting existing keys, directory creation, file permissions, or what output is returned. This lack of transparency could lead to unexpected behavior in workflows.

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

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

The description is one short sentence, front-loaded with the core action and resource. It is highly concise with no wasted words, making it easy to parse quickly.

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

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

This is a mutation tool with no output schema and no annotations. The description is too sparse to be considered complete: it doesn't explain return values, behavioral constraints, or edge cases like path conflicts. The agent would need additional information to invoke it safely and effectively.

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

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

The input schema covers all parameters with descriptions (100% coverage). The description adds no further semantic meaning beyond what the schema already provides, 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.

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

The description is concise and specific: 'Generate a new SSH key pair' clearly states the action (generate) and resource (SSH key pair). It distinguishes from sibling tools like ssh_list_keys or ssh_fingerprint, 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.

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention typical use cases, prerequisites (e.g., needing a passphrase), or situations where another tool might be more appropriate. For a key generation tool, this leaves the agent without context for selection.

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

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 only says 'List available SSH keys' without explaining what 'available' means, which directory is scanned (beyond the schema default), or whether it returns file paths or key details. This is insufficient for a tool with no other metadata.

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

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

The description is a single, clear, and efficient sentence. It is front-loaded with the verb and resource, containing no wasted words. Slightly more detail could be added without harming conciseness, but the current form is acceptable.

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

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

The tool is simple, but with no output schema and no annotations, the description should mention what the output looks like or what 'available' means (e.g., private keys in the directory). The lack of any such context leaves the tool under-specified, especially given the diversity of sibling tools.

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

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

The input schema fully documents the 'directory' parameter with a description and default. The description adds no additional semantic information. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states the action ('List') and the resource ('available SSH keys'), which distinguishes it from siblings like ssh_keygen or ssh_fingerprint. However, it lacks explicit mention of the directory scope, which is only available in the parameter schema, and does not explicitly contrast with sibling tools.

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

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_fingerprint or ssh_keygen. The description is purely the action and resource, leaving the user to infer usage from the tool name.

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

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

With no annotations provided, the description carries the full burden. It discloses that the operation is read-only via the verb 'list' and specifies the 'active' status of sessions, which adds some behavioral context. However, it does not mention whether the output includes session details, authentication requirements, or any side effects beyond listing.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It is exceptionally concise and to the point.

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

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

Although the tool is simple with no parameters, the description does not explain what the returned list contains (e.g., session IDs, hosts, usernames) or how to interpret 'active'. There is no output schema, so the description should compensate with more detail about the return value, but it remains minimal.

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

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

The tool has zero parameters, so the schema is trivially 100% covered. The description adds no parameter info, but the baseline for 0 params is 4, and there is nothing that requires compensation.

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

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

The description uses a specific verb 'List' and a clear resource 'all active SSH sessions'. It distinguishes itself from sibling tools like ssh_list_keys or ssh_get_config by focusing on sessions, making the purpose unmistakable.

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

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

The usage is implied by the tool name and description: if you need to list active SSH sessions, this is the tool. However, there is no explicit guidance on when to use it versus alternatives like ssh_connect or ssh_disconnect, nor any mention of prerequisites or exclusions.

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

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

No annotations are provided, so the description must disclose side effects, prerequisites, and state changes. It only says 'create a tunnel' without explaining that it establishes a persistent forwarding, requires an active SSH session, or may modify session state. No return value or error behavior is mentioned. Lacks transparency for a mutating operation.

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

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

The description is a single sentence, front-loaded with the action and purpose. It contains no fluff, repetition, or unnecessary detail. Efficient and appropriately sized.

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

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

The tool has 5 parameters, no output schema, and no annotations. The description is too minimal to support correct invocation in all cases: it fails to mention that sessionId must refer to an existing session, that type determines the direction of forwarding, or what a successful creation returns. While the schema provides parameter names, it does not explain the operational context needed for an agent to confidently use the tool.

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

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

Schema description coverage is 100% with each parameter having a brief description. The tool description adds no additional meaning beyond the schema's parameter titles and basic details. It does not clarify the interplay between type, localPort, remoteHost, and remotePort (e.g., which are required for each type). Baseline of 3 is appropriate since the schema covers all parameters, but the description adds minimal value.

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

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

The description clearly states the action (Create) and target (SSH tunnel) with the purpose (port forwarding), distinguishing it from sibling tools like ssh_connect and ssh_execute. It does not explicitly differentiate from ssh_close_forward but the verb 'create' makes that clear. Slightly generic but sufficient.

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

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_connect, sftp_upload, or ssh_close_forward. The description does not mention prerequisites (e.g., an existing session via sessionId) or whether local/remote/dynamic types require different usage contexts. There is no 'when-to-use' or exclusion language.

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

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 indicates a mutation ('set') but does not disclose whether the change persists, affects only the current session, requires specific privileges, or what happens to existing options. No side effects or usage details are mentioned.

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

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

The description is a single concise sentence that is front-loaded and contains no fluff. It is efficient, though it provides minimal additional value beyond the tool name itself.

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

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

For a mutation tool with no annotations and no output schema, the description is too sparse. It does not explain the return value, the scope of change (persistent vs. session-only), or relate to sibling tools like ssh_get_config. However, the parameter schema is fully described and the operation is simple, preventing a score of 1.

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

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

The input schema already describes both parameters (key, value) with 100% coverage. The description adds no extra semantic information about valid keys, value formats, or examples, so it does not go beyond the baseline for well-covered schemas.

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

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

The description states 'Set an SSH configuration option' with a specific verb (set) and resource (SSH configuration option). It is clear and unambiguous, but it does not explicitly differentiate from sibling tools beyond the verb, and it largely restates the tool name.

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

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

No guidance is given on when to use this tool versus alternatives like ssh_get_config, or any context about session requirements or scope. There is no mention of exclusions or alternative approaches.

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