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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and target but omits critical details such as whether the removal is irreversible, whether it deletes only exact matches, and how missing host entries are handled. For a destructive operation, this is insufficient.

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

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

The description is one concise sentence with no filler, front-loading the action and target. Every word earns its place.

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?

While the schema covers the parameter, the description lacks details about edge cases and return behavior. With no output schema, it could mention success indications or the irreversible nature of the deletion. The tool is simple, but some gaps remain in fully understanding expected behavior.

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 fully describes the single 'host' parameter with a clear description. The tool description adds no additional semantics beyond restating that it removes entries for that host. Baseline 3 is appropriate when schema coverage is 100%.

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 identifies the tool's purpose: removing stale or changed host entries from the local known_hosts file. It specifies the exact resource and action, distinguishing it from siblings focused on connection, execution, and file transfer.

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 when host keys are stale or changed, but does not explicitly state when not to use this tool or point to alternatives. The context is clear enough for an agent to infer appropriate usage, but it lacks explicit exclusion guidance.

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 says 'Download a remote file,' which implies a read from remote and write to local, but it does not disclose whether existing local files are overwritten, whether directories are created, or what error conditions might arise (e.g., authentication failures). This is a significant gap for a file transfer 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, concise sentence that is front-loaded with the primary action and target. It is appropriately sized and contains no wasteful filler.

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 7 parameters, no output schema, and no annotations, the description is too sparse. It does not indicate what the tool returns (e.g., success message, file size), how authentication works, or any edge cases. The tool's complexity demands more context than a simple one-liner.

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 7 parameters. The description adds no additional parameter semantics. The baseline score of 3 is appropriate because the schema handles the heavy lifting.

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 ('Download') and the resource ('a remote file'), and adds the transport mechanism ('via SFTP channel'). This distinguishes it from sibling tools like ssh_upload_file (opposite direction) and ssh_exec (command execution).

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 that it is for file transfer rather than command execution, nor does it note authentication prerequisites (e.g., password vs. private key). No exclusions or alternative tool recommendations are given.

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 transparency burden. It discloses specific technical behaviors such as Base64 UTF-16LE encoding, Session 0 bypass, 8191-character limit bypass, and dual authentication, which go beyond a simple statement of purpose and provide useful context about the tool's operation.

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

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

The description is a single sentence that front-loads the main purpose and then lists key capabilities in a compact manner. Every word contributes meaningful information, with no fluff or redundancy.

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 complex (9 parameters, no output schema, no annotations) and the description omits crucial information such as return values, exit codes, error handling, and authentication details beyond the vague 'dual auth.' The description does not fully equip an agent to understand the tool's complete behavior.

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%, so the baseline is 3. The description enriches parameter understanding by explaining that Base64 UTF-16LE relates to command encoding and that Session 0 bypass relates to desktop session handling, adding value beyond the schema's individual parameter descriptions.

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's function: 'Execute remote commands over SSH.' It distinguishes itself from siblings like file transfer and connection testing by focusing on command execution, making its purpose 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 implies usage for running commands remotely but does not explicitly state when to use this tool versus alternatives. It provides no exclusions or comparisons with sibling tools, leaving the usage context inferred.

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. It transparently discloses the core behavior (generates a PowerShell install script), but doesn't elaborate on how the host and userType parameters shape the script, or whether the script triggers side effects like firewall changes or reboots. Some secondary behavioral details remain opaque.

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 zero redundancy. Every word adds information: the action ('Generate'), the format ('1-liner PowerShell script'), the delivery channel ('copy-paste into RDP'), and the goal ('install OpenSSH server').

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 description covers the essential output and purpose for a simple generation tool with no required parameters and a rich schema. It doesn't explicitly explain how this tool fits into the broader SSH workflow (e.g., enabling later ssh_* operations), but that is inferable from sibling names and the stated goal.

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 provides high coverage (100%), with clear descriptions for both parameters: host as 'Target host IP or hostname' and userType as an enum with admin/user meanings. The description adds no additional parameter semantics, 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 uses a specific verb ('Generate') and resource ('1-liner PowerShell script to install OpenSSH server'), clearly distinguishing it from sibling tools that test connections, execute commands, or transfer files. The 'RDP session' context further pinpoints the exact workflow.

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 clearly states the usage context: copying the script into an RDP session to bootstrap OpenSSH on a Windows target. It doesn't explicitly list alternatives or when not to use, but the purpose is distinct enough from siblings that no further exclusion is needed.

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. It discloses the primary destructive behavior (removing keys/clearing all) and consequence (revoking passwordless login), but doesn't mention authentication prerequisites, lockout risks, or reversibility.

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?

One sentence that conveys the action and scope efficiently without wasted words. It front-loads the primary function.

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 8 parameters and no output schema, and the description is minimal. It doesn't explain authentication prerequisites or failure modes, though the schema covers parameter semantics. It's sufficient for a straightforward revocation tool but lacks deeper behavioral context.

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 has 100% coverage for parameter descriptions, so the baseline is 3. The description adds no specific parameter details beyond what's in the schema, but it does align the 'remove specific key' vs 'clear all' options with keyPathToRemove and removeAllKeys.

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's action ('Remove public key entry or clear ALL keys from authorized_keys') with specific resource and purpose, distinguishing it from siblings like ssh_setup_passwordless and ssh_clear_known_hosts.

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 the usage context (revoking passwordless SSH login) and clearly differentiates the two modes (specific key vs all keys). It doesn't explicitly name alternatives, but the tool's function is self-evident in context.

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 transparency burden. It discloses target file paths and Windows ACL handling, plus verification of key login. However, it omits side-effects like modifying authorized_keys, whether it generates a key pair, or what happens on key mismatch (though forceOverwrite param hints at this). The description provides useful but incomplete behavioral context.

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

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

The description is a single, well-structured sentence that front-loads the action and includes essential details (target OS paths, ACL mention, verification). Every word adds value, with no redundancy or fluff.

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

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

Given the tool's complexity (7 params, multi-OS support, verification step), the description covers the core purpose and key behavioral aspects but lacks details on return values, error handling, prerequisites, and side-effects. It is sufficient for a high-level understanding but leaves operational gaps that could be covered by annotations or a more thorough description.

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 baseline is 3. The description adds context about ed25519 key type and deployment destinations, but does not elaborate on parameter semantics beyond what the schema already documents. The keyPath parameter's private/public key ambiguity is not clarified in the description.

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 'Deploy', the resource 'ed25519 public key', and the specific destinations (Linux ~/.ssh/authorized_keys, Windows administrators_authorized_keys with ACLs). It distinguishes this tool from siblings like ssh_remove_passwordless and ssh_test_connection by implying a setup action for passwordless login.

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 the tool is used to enable passwordless SSH login, but it does not explicitly state when to use it over alternatives or provide exclusions. Context from the tool name and siblings suggests usage, but there is no direct guidance on selecting this vs. ssh_test_connection or ssh_remove_passwordless.

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 discloses a notable behavioral trait: outputting an RDP script if the server is unreachable/uninstalled. However, it does not mention potential side effects (e.g., known_hosts modification) or detail what happens on a successful connection beyond 'probe target OS.'

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 that front-loads the primary action and includes the key fallback behavior. It is concise, readable, and free of unnecessary 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?

The description is incomplete for a tool with no output schema or annotations. It does not specify what is returned on a successful connection (e.g., OS type), what 'uninstalled' means, or any side effects or prerequisites. Agents need more detail to fully understand the tool's behavior.

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?

All 5 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds no additional parameter-level information or context beyond what the schema already provides.

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's action: 'Test SSH connection & probe target OS.' It also mentions a distinct fallback behavior (outputs RDP 1-liner script), which helps differentiate it from sibling tools like ssh_exec or ssh_upload_file. The verb and resource are specific and unambiguous.

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

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

The description implies usage through its purpose, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or direct comparisons to sibling tools. The fallback behavior gives some context but no formal guidance.

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 carry the full burden of behavioral disclosure. It only states the basic upload action and does not disclose whether the remote file is overwritten, whether directories are created automatically, or any side effects. Authentication requirements are present only in the schema, not the description.

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

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

The description is a single, clear sentence with no fluff or redundant information. It is front-loaded with the core action and resource, making it easy to parse. While it is terse, it is not under-specified to the point of being unhelpful.

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 absence of annotations and output schema, the description is too sparse to guide correct use in all situations. It does not mention prerequisites (e.g., local file existence), authentication choices, or behavior on conflicts, which are essential for a file-transfer tool. The schema covers parameter syntax but not operational context.

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%, meaning the schema already documents all parameters (e.g., localPath, remotePath, password, privateKeyPath). The description adds no additional semantic meaning, such as the relationship between password and privateKeyPath or path format requirements, but the baseline of 3 is appropriate due to full schema coverage.

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 clearly identifies the resource ('local file to remote host via SFTP channel'). It unambiguously distinguishes this tool from siblings like ssh_download_file (opposite operation) and ssh_exec (command execution).

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 use when a file needs to be transferred to a remote host via SFTP, but provides no explicit guidance on when not to use it or which alternatives to consider. Sibling tools exist (e.g., ssh_download_file) but are not referenced, so the agent must infer usage from the tool name and description alone.

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