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

注解已声明 readOnlyHint、destructiveHint=false 和 openWorldHint=false，因此安全侧已覆盖。描述额外补充了重要行为背景：不会泄露密码、私钥或口令，且不会打开连接——这是专门针对凭证处理工具的有价值披露，而非重复注解内容。

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?

单句表述，先说明用途，后补充两项限制。零冗余内容，每个分句都增添了独立信息。

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?

对于无参数、无输出 schema、免认证的读取工具，描述已充分说明工具作用及不会发生的情况。输出结构（例如返回哪些字段）未作说明，但由于其返回结构简单，且描述已清楚表明工具属于只读清单类，这一缺口并不严重。

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?

该工具接受零个参数，因此基线为 4。描述正确未虚构任何输入；schema 为空且覆盖率为 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?

句首以明确的动词+资源开头（'查看已配置的 SSH 目标及限制'），描述内容清晰可辨。'不连接远程主机'这一否定说明有效将其与 ssh_test_connection / ssh_exec 区分开来，不过并未点出具体兄弟工具的名称。

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?

使用场景可推断（检查已配置的 SSH 目标），'不连接远程主机'也暗示了不应使用的时机。但未列出替代方案或选择此工具与其他 ssh_* 工具的条件。

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: the write target is the local absolute path and an existing local file causes a refusal rather than a silent overwrite. It does not mention permissions, partial-transfer behavior, or error surface.

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?

A single front-loaded sentence covering direction, destination semantics, and the no-overwrite rule with zero filler. Every clause 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?

With no output schema and only two required parameters, the description supplies enough to call the tool correctly: transfer direction, parameter roles, and the failure condition. It omits what a successful transfer returns and any connection/prerequisite context, which would complete the picture.

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 0%, so the description must compensate, and it does: it clarifies that localPath is an absolute path and that remotePath refers to a path on the remote host. It adds no format/syntax detail (e.g., whether remotePath is relative to home, glob support), leaving a small gap.

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?

States a specific verb and resource ('从远程 SSH 主机下载文件到本地绝对路径'), making the transfer direction unambiguous, which implicitly separates it from the sibling ssh_upload. It does not name any sibling explicitly, so it falls short of a 5.

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 embeds one useful usage condition (refuses to overwrite an existing local file), which tells the agent when the call will fail. However, it gives no guidance on choosing this over ssh_upload/ssh_exec or on required connection context, so usage is only implied.

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?

Annotations already declare destructive/openWorld/non-idempotent, and the description goes well beyond them: full SSH-user permissions, potential data modification or deletion, stateless per-call connections (no cd or env retention), no automatic retry, and an explicit prompt-injection warning that output is untrusted remote data rather than instructions.

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?

Every sentence is front-loaded with load-bearing information — capability, permission scope, statelessness, retry behavior, output trust — and none of it is padding or restatement of the title. Appropriate length for a destructive, open-world tool.

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 output schema and full parameter coverage in the schema, the description supplies exactly the missing behavioral context: statelessness, destructive potential, no-retry semantics, and how to treat returned data. Nothing an agent needs to call this safely is absent.

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% for both parameters, so the baseline is 3. The description reinforces that directories must be handled with an explicit cd inside the command (already in the schema) but adds no new syntax, format, or timeout semantics beyond what the schema documents.

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 a specific verb and resource — executing a command in the configured remote host's default shell — and adds the discriminating scope qualifiers (non-interactive, no PTY). An agent can distinguish it from ssh_upload/ssh_download/ssh_test_connection purely from this sentence.

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?

It gives a prerequisite ('confirm user authorization before execution') and an implicit when-to-use by describing what the tool does, but it never names alternatives or the conditions under which another sibling (e.g. ssh_test_connection) is preferable. Usage is implied rather than 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds that it tests connection, fingerprint, and authentication without executing commands, but does not describe failure modes, timeouts, or return behavior.

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 concise sentence, front-loaded with the core action and scope, and ending with a key constraint. No wasted 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 simple no-parameter connectivity test with annotations covering safety, the description is nearly complete. It states what is tested and that no commands are executed, though it omits what a test returns or how failures are reported.

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 baseline 4 applies. The empty schema and description provide no parameter semantics to clarify, which 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?

States a specific verb (测试/test) and resources (SSH host connection, fingerprint, authentication), and explicitly says it does not execute commands, which implicitly contrasts with ssh_exec. It does not name sibling alternatives directly, so not a 5.

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?

Usage is implied: use this to verify a configured SSH host without running commands. However, it gives no explicit when-to-use guidance, prerequisites, or named alternatives like ssh_connection_info.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the write/risk profile is covered structurally. The description adds one genuinely new behavioral constraint — the remote target must be an absolute path — but says nothing about overwriting existing files, permission failures, or directory creation.

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?

A single compact sentence that front-loads the action and target with zero filler. Nothing redundant or padded.

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 two-parameter mutation tool with no output schema, the essentials (overwrite semantics, connection prerequisites, error behavior) are missing. The description is adequate to invoke the tool but incomplete for predicting its side effects.

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 0%, so the description must carry the load. It clarifies that localPath is a local file and remotePath is an absolute remote path, which adds real meaning, but gives no format examples, path syntax, or escaping details.

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?

States a specific verb (上传/upload) and resource (本地文件 -> 远程 SSH 主机绝对路径), which is precise enough to separate it from ssh_download. It does not explicitly name or contrast any sibling, so it stops short of a 5.

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?

There is no when-to-use framing, no prerequisites (e.g., must already have an SSH connection established), and no mention of alternatives such as ssh_download or ssh_exec. The intended use can only be inferred from the verb.

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