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 says nothing about whether an existing local file is overwritten, whether parent directories are created, whether the transfer is atomic/streamed, what happens on a missing remote file, or what the tool returns — all material for a tool that writes to the local filesystem.

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 with the operation and direction stated first and no filler. It is efficient, though the terseness is also what leaves the behavioral gaps unaddressed.

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?

No output schema and no annotations mean the description must cover behavior, yet it omits overwrite semantics, directory creation, error cases and connection prerequisites. For a tool in a 16-sibling SSH/SFTP suite, that is insufficient to call it safely.

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 remotePath, localPath and connectionId are already documented (including the default-connection fallback for connectionId). The description adds no format, path-syntax or connection-selection detail beyond the schema, so the baseline 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?

States a specific verb (下载/download) and resource (文件/file) with an explicit direction (远程主机 → 宿主机本地路径), which cleanly separates it from the sibling sftp_upload. It does not name any sibling, but the directional wording makes the distinction obvious without opening a schema.

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 guidance, no prerequisites (e.g. an active connection or ssh_connect having been called), and no mention of alternatives such as sftp_read_file for reading contents versus downloading a whole file. The agent is left to infer context entirely.

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 behavioral burden. While '列出' implies a read-only operation, it omits key details such as authentication requirements, pagination, symlink handling, and whether the operation has any 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.

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

The description is a single, front-loaded sentence with no wasted words. However, its extreme brevity leaves gaps that could be addressed without sacrificing conciseness.

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 the absence of an output schema means the description should ideally explain the return structure or metadata fields. It only states that a metadata list is returned, without specifying fields like name, size, or type, and no annotations cover safety or 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 description coverage is 100%, and the schema fully documents both parameters. The description adds no additional meaning beyond what the schema already provides for remotePath and connectionId, 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 specifies the verb ('列出') and resource ('远程目录下的文件与子目录'), clearly identifying a directory-listing operation. It does not explicitly differentiate from siblings like sftp_stat or sftp_read_file, but the purpose is 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?

No guidance is given on when to use this tool versus alternatives such as sftp_stat (for single file metadata) or sftp_read_file (for file contents). The description only states what it does, leaving the agent to infer appropriate usage contexts.

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 behavioral burden. It hints at idempotent-style behavior via the 'mkdir -p' analogy, but says nothing about error handling when the directory already exists, permission requirements, or what happens on partial failure – and the mkdir -p note merely repeats the schema's own recursive parameter text.

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 short sentence with the core operation front-loaded and a brief parenthetical qualifier; nothing is padded. The parenthetical is mildly redundant with the schema, keeping it just under a 5.

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 mutation tool with full schema coverage and no output schema, the description is minimally adequate. It leaves out existence/overwrite behavior and connection prerequisites, which an agent would want before invoking a remote write.

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 all three parameters are already documented in the schema; baseline 3 applies. The description's parenthetical about recursive parent creation duplicates the schema text for the recursive parameter rather than adding new meaning.

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+resource: creating a directory on a remote host, which is inherently distinguishable from siblings like sftp_write_file, sftp_upload, or sftp_list_dir. It does not explicitly name or contrast with a sibling, so it stays at 4 rather than 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 offers no when-to-use guidance, no prerequisites (e.g. that a connection must exist or that connectionId/current default is used), and no mention of alternatives. Usage is only implied by the verb itself.

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 behavioral burden. It usefully discloses the hard 512KB read cap and that exceeding it triggers interception plus a download suggestion, which is real behavior beyond the schema. However, it says nothing about error behavior, binary/encoding failure handling, permission requirements, or what the call returns.

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 with the core action front-loaded and the limit/fallback parenthesized after it. Every clause earns its place; nothing is redundant 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 4-parameter read tool with no annotations and no output schema, the description covers the critical size constraint but omits what the caller receives (text content string?), how binary or oversized content behaves in practice, and default-connection behavior. Adequate but with clear 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%, so all four parameters (encoding, maxBytes, remotePath, connectionId) are already documented in the schema; this is the baseline case where the schema does the heavy lifting. The description's 512KB mention merely restates the maxBytes default/limit rather than adding new semantics.

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 ('读取远程主机文本文件内容'), so an agent immediately knows this reads a remote text file rather than writing, listing, or stat-ing one. It implicitly routes oversized reads toward the download sibling ('超出建议下载') but never names sftp_download explicitly, so it stops short of full sibling differentiation.

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?

Gives a clear use condition (reading remote text file content) and an implicit when-not: files exceeding the 512KB single-read limit should go to a download instead. There is no explicit prerequisite or connection guidance, but the boundary condition for choosing an alternative is present.

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 and does reasonably well: it discloses recursive cascade behavior and built-in loop protection. However, it does not state whether deletion is permanent/irreversible or whether permissions are required, which matters for a destructive 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?

Single compact sentence in a parenthetical structure; front-loaded with the core action and supplementary behaviors. Slightly dense but 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 destructive tool with no annotations and no output schema, the description covers recursive behavior and loop protection but omits irreversibility, permission requirements, and error/return behavior. Adequate but leaves meaningful gaps for a delete operation.

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 all three parameters (recursive, remotePath, connectionId) are fully documented in the schema. The description mentions recursive deletion at a high level but adds no syntax or format detail beyond the schema. Baseline 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?

States a specific verb+resource ('删除远程文件或目录' = delete remote file/directory) and adds distinguishing details (non-empty directory recursive cascade deletion, built-in loop protection). Clear enough to separate from siblings like sftp_upload or sftp_write_file, though it doesn't explicitly name an alternative.

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 on when to use this vs alternatives or when to avoid it. The recursive default of false implies a safety posture, but there is no explicit when/when-not instruction or prerequisite (e.g., connection state) mentioned.

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 behavioral burden. '获取…信息' implies a read-only, non-destructive operation, which is useful, but it says nothing about error behavior for missing paths, symlink handling, or whether a connection must already be open.

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 with no filler. It is efficient, though it is arguably too terse to carry the missing usage and behavioral context the tool needs.

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 two-parameter read tool with full schema coverage, the description is minimally sufficient to invoke correctly. With no output schema and no annotations, it could have disclosed what metadata is returned and how failures surface, but it stops short.

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 both remotePath and connectionId (including its default-connection fallback) are already documented in the schema. The description adds no format, path-style, or defaulting detail beyond that, so the baseline 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 states a specific verb (获取/get) and resource (remote file or directory POSIX metadata), so an agent knows this retrieves metadata for a single path rather than listing contents. It does not, however, name or distinguish itself from the closest sibling, sftp_list_dir.

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 guidance on when to use this instead of sftp_list_dir or sftp_read_file, nor any mention of prerequisites (e.g., an active connection). The agent must infer usage entirely from the name and the 'file or directory' phrasing.

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 behavioral burden. It claims a 'fast' upload but says nothing about overwrite behavior on an existing remote file, required permissions, connection requirements (connectionId defaults to the current connection), or how failures are reported — all material for a mutation tool with zero annotation coverage.

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 short sentence with no filler, and the source-to-destination framing is front-loaded. It is efficient but so terse that it forgoes any useful elaboration.

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 3-parameter tool with a fully documented schema and no output schema, the description is just barely sufficient. It omits overwrite semantics, error behavior, and any statement of what distinguishes it from sftp_write_file, which a mutation tool with no annotations should cover.

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 localPath, remotePath and connectionId are already documented in the schema, including the default-connection behavior. The description adds no syntax, path format, or override details beyond that, 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?

States a specific verb (上传/upload), the source (宿主机本地文件) and the destination (远程目标主机), so the agent knows the direction of transfer. It does not distinguish itself from the sibling sftp_write_file, which also writes to a remote path, leaving ambiguity about which to pick.

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 gives no when-to-use or when-not-to-use guidance and never names an alternative such as sftp_write_file or sftp_download. An agent must infer selection purely 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?

No annotations exist, so the description carries the full burden. It does disclose two meaningful traits beyond the schema: the write overwrites existing content, and parent directories are auto-created recursively. But it omits encoding, error behavior on failure, permission requirements, and whether the overwrite is atomic or truncating.

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 tight sentence with the core action front-loaded and secondary behavior in parentheses. No filler, though it is on the sparse side for a mutation 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?

For a 4-parameter write tool with no annotations and no output schema, the description covers the essential overwrite-and-create behavior but leaves unanswered what happens on failure, how existing file contents are affected mid-write, and whether special handling applies to non-text content.

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 all four parameters are already documented, setting the baseline at 3. The description reinforces the createDirectories default behavior but adds no syntax, path-format, or content-type details beyond what the schema states.

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 ('写入并覆盖远程主机文本文件') and adds the qualifier 'text file', which implicitly separates it from the binary-oriented sftp_upload sibling. However, it never names or contrasts with any sibling explicitly, so differentiation is left to inference.

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 or when-not-to-use guidance. The phrase '文本文件' hints that binary transfers belong to sftp_upload, but the agent is not told this, nor are prerequisites (connection setup, permissions) or the relationship to sftp_mkdir described.

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 full burden. It only states that it establishes or loads a connection; it omits authentication flow, connection persistence, error handling, and whether the connection becomes the default active connection (setAsDefault is only in schema).

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 with no filler. It efficiently conveys the core purpose and the alias-based alternative.

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 12-parameter connection tool with no annotations and no output schema, the description is too thin. It does not explain that this creates a persistent connection usable by ssh_exec/ssh_session_* tools, nor does it cover authentication expectations or lifecycle management.

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 12 parameters. The description adds a small hint about ~/.ssh/config alias usage but does not explain parameter syntax or interactions beyond that.

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+resource (建立 SSH 主机连接) and an alternative mode (载入 ~/.ssh/config 别名). It clearly distinguishes from siblings like ssh_exec or sftp_* which operate on an existing connection.

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?

Describes two connection modes but gives no guidance on when to use this tool versus ssh_session_start, ssh_ping, or other siblings. No prerequisites or when-not conditions are provided.

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 states that a connection is closed but omits whether the connection must be active, what happens on failure, whether the operation is reversible, or any side effects on sessions tied to the connection.

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 with no wasted words that names the action and its target directly.

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 one-parameter tool with no output schema this is minimally adequate, but with no annotations and no differentiation from ssh_session_close, an agent lacks enough context to choose confidently between the two.

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% and the single connectionId parameter is fully documented in the schema. The description adds no meaning beyond what the schema already provides, 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 gives a specific verb pair (断开/关闭) and resource (指定的 SSH 物理网络连接), making the operation clear. It does not, however, differentiate itself from the sibling ssh_session_close, which an agent could easily confuse with closing a connection.

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 explicit statement of when to use this tool versus alternatives such as ssh_session_close or when not to call it. Usage is only implied by the tool name and verb.

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 at all, the description carries the full behavioral burden. It does disclose two important traits: the call is stateless and it returns exit code, stdout and stderr. It says nothing about the safety-interception guard (which can refuse or block a command), authentication requirements, or connection routing behavior — a notable gap for an execution tool with no annotation coverage.

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, tightly packed sentence with zero filler, front-loading the action, target and scope before the return contract. Nothing is redundant and nothing is buried.

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?

There is no output schema, and the description compensates by stating the return contract (exit code, stdout, stderr), which is exactly what an agent needs. The safety-guard and connection-routing behavior is largely covered by the parameter descriptions in the schema, but the absence of any annotation means some operational context (auth, blocking semantics) remains unstated.

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 all eight parameters (including cwd, env, dryRun, rawExec, timeoutMs, connectionId, dangerouslySkipSafetyCheck) are already documented in the schema. The description adds no parameter-level detail beyond what is structured, 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 names a specific verb+resource (execute a Bash/Shell command on a remote Linux host) and adds the scope qualifier '单次无状态' (single, stateless), which cleanly separates it from the stateful ssh_session_send/session tools. An agent can distinguish it from every sftp_* and ssh_session_* sibling without opening a schema.

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 phrase '单次无状态' implies when this tool is appropriate (one-shot commands, no persistent shell state), which is useful context. However, it never names an alternative or an exclusion condition, so the agent must infer that ssh_session_start/send exists for multi-step stateful work.

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 behavioral burden. It usefully discloses the data source (~/.ssh/config) and the read-only nature implied by 读取并列出, but says nothing about failure behavior when the file is missing or malformed, or whether values are masked. For a zero-parameter read tool this is acceptable but not rich.

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 with no filler; the action and the data source appear before any detail. 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, the description does sketch the return contents (all Host aliases and their basic configuration), which is the key missing piece an agent would need. No annotations or params exist to be explained, so only the edge-case behavior is left unstated.

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 takes zero parameters, which is the baseline-4 case. The description also previews what is returned (Host aliases plus basic configuration), adding modest value, though there is no parameter surface to elaborate on.

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 pair (读取并列出 / read and list) and a precise resource (Host aliases in the local ~/.ssh/config), which clearly separates it from ssh_list_connections (live connections) and the sftp_* tools. It does not explicitly name a sibling for contrast, but the resource is narrow enough that an agent can disambiguate without opening the schema.

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 its usage context (inspecting the parsed local SSH config) but gives no explicit when-to-use guidance, no prerequisites (e.g., whether the file must exist), and no exclusions relative to ssh_list_connections or ssh_connect. Adequate but leaves the routing decision to inference.

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 exist, so the description must carry the behavioral burden. It discloses scope (only established/alive connections, includes default route state) and '列出' implies a read-only, non-mutating operation, but it says nothing about required permissions, whether it contacts remote hosts, or the shape of results.

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 tight sentence, front-loaded with the primary resource and with no redundant or padded clauses. Every phrase (established/alive, default route) contributes scope.

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 zero-parameter, no-output-schema read tool, the description is nearly sufficient: it tells the agent what is enumerated and adds the default-route scope. Only minor gaps remain, such as whether results include per-connection status detail or routing table contents.

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 takes zero parameters, so there is no parameter semantics to document; the 4 baseline applies. The description correctly avoids inventing parameters and adds no misleading signature information.

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+resource: listing currently established and alive SSH connections, plus default route status. The 'established and alive' qualifier implicitly distinguishes it from the config-listing sibling ssh_list_config_hosts, but it never names that sibling or any other, so differentiation is left to inference.

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 by the resource ('list active connections' clearly signals a monitoring/inspection use), but there is no explicit when-to-use, when-not-to-use, or reference to alternatives such as ssh_list_config_hosts or ssh_session_start. Adequate but leaves routing to inference.

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, and it does disclose the observable behavior (liveness, version, latency) which hints at the response. However it says nothing about whether it is read-only, whether it opens a network connection, or what side effects the echoed message has, leaving real behavioral gaps.

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 clause that states the resource and the three things it verifies, with zero filler. Nothing is redundant and nothing needs to be moved.

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 one-optional-parameter diagnostic tool with no output schema and no annotations, the description's enumeration of liveness/version/latency effectively conveys what comes back and is sufficient to call it. Only the echo parameter's purpose is left entirely to the 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?

Schema description coverage is 100% and the single optional 'message' parameter is documented as an echo payload in the schema. The description adds no semantics for it, so the baseline of 3 applies with the schema doing the work.

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 names a specific verb (测试/test) and resource (SSH MCP 服务) and enumerates what it checks: liveness, version info, and latency. This clearly separates it from siblings like ssh_exec or sftp_* which act on remote hosts rather than the local service itself, though it never explicitly references an alternative.

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 only implied: a health/latency probe is naturally used for diagnostics or connectivity checks before connecting, but the description never states when to call it versus ssh_connect or ssh_list_connections. No prerequisites or exclusions 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?

No annotations are provided, so the description carries full behavioral disclosure. It states that the session is closed and resources reclaimed, but omits whether termination is graceful or abrupt, what happens to running processes, required permissions, error behavior, and whether the operation is irreversible.

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 with no redundant or filler content. It states the action and the resource immediately and ends cleanly.

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 one-parameter close tool with a fully described parameter, the description conveys the essential purpose and cleanup effect. However, with no annotations and no output schema, it should disclose more about side effects and safety to be fully complete for a destructive-style operation.

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% and the single sessionId parameter is fully documented in the schema. The description adds no additional meaning, format, or constraints beyond what the schema already provides, 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?

States a specific verb (关闭) and a precise resource (指定的持久交互式 PTY 终端会话), including a cleanup outcome (回收系统资源). It does not explicitly distinguish itself from siblings such as ssh_disconnect or ssh_session_send, 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?

No when-to-use guidance, prerequisites, or alternative tools are named. The usage is only implied by the action of closing a session; there is no explicit context for choosing this tool over ssh_disconnect or other session or connection operations.

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 add real behavioral value by disclosing that the call collects incremental screen echo and by showing that raw control bytes are accepted, but it is silent on error handling, whether a trailing newline is needed, what happens to a closed/expired session, and other side effects of writing to a live PTY.

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 with the action first and the control-signal example parenthetically attached. No padding 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?

For a three-parameter interactive I/O tool with no output schema, the description adequately covers what is written and that incremental screen output is returned, and the schema fills in the rest. Only the absence of session-lifecycle/error expectations keeps it from being fully 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?

Schema description coverage is 100%, covering input, sessionId, and waitForMs, so the schema already documents all three parameters. The description only restates the control-character example already present in the input schema, adding no new semantics such as expected byte encoding or how waitForMs truncates output.

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 (写入/write input or control signals) against a specific resource (指定的持久 PTY 终端/persistent PTY session), and the Ctrl+C example makes the intent concrete. It implicitly separates itself from one-shot ssh_exec by insisting on a persistent PTY, but never names a sibling explicitly.

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 mention of a 'persistent PTY session' implies this is for interactive sessions started via ssh_session_start, but the description never states when to choose this over ssh_exec or how it relates to ssh_session_close. Usage is inferable 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?

With no annotations, the description must carry the full behavioral burden. It usefully discloses that the session is persistent and state-preserving, but omits lifecycle facts: that it must be driven by ssh_session_send and torn down with ssh_session_close, whether sessions are resource-limited, or what happens on reconnect.

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 with no filler; the core action and its key differentiator (persistent state) come first.

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 session-lifecycle tool with no annotations and no output schema, the description covers what it does but not how the returned session is used or closed. An agent still needs the sibling tools to understand the full lifecycle, leaving a real gap.

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 cols, rows, and connectionId are already documented in the schema (including defaults and the default-connection routing behavior). The description adds no parameter-level meaning, so the baseline 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?

States a specific verb and resource: start a persistent interactive PTY session on a remote host. The qualifiers '持久交互式' and '跨多次输入维持环境状态' implicitly separate it from the one-shot ssh_exec sibling, though no sibling is named explicitly.

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?

Gives clear context for when to use it — when an agent needs an interactive session whose state survives multiple inputs. It stops short of stating exclusions or naming ssh_exec/ssh_connect as alternatives, so it is clear context without routing guidance.

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