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?

With no annotations, the description carries the full burden. It describes the tar-stream mechanism but omits critical behavior: whether local files are overwritten, whether the target directory must exist, permission requirements, symlink handling, and error behavior during partial extraction.

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 little waste. The implementation detail about 'pure JS streaming Tar architecture' is somewhat unnecessary for an agent, but it does not obscure the main purpose.

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 that mutates the local filesystem by extracting an archive, the description is incomplete. With no annotations and no output schema, it should clarify overwrite behavior, local directory creation, and failure semantics.

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 input schema already documents each parameter thoroughly. The description does not add parameter-specific meaning beyond what the schema provides, making the baseline 3 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 states a specific action and resource: package a remote directory and stream-download/extract it locally. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like sftp_download or sftp_upload_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 tool versus alternatives such as sftp_download for single files or sftp_upload_dir. The implied use case is downloading a directory, but no conditions, exclusions, or prerequisites are 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?

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 disclosure burden. It usefully discloses atomicity and the avoidance of line-number drift and full rewrites, but says nothing about permissions, failure behavior when the target is not found, or whether changes are reversible.

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 dense sentence that front-loads the core operation (atomic anchor-based replacement) followed by the risk it avoids. No filler, nothing redundant.

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 complete schema coverage and no output schema, the description covers the tool's nature and its key differentiator (no line-number drift). It remains thin on mutation-side behavior such as error handling, but for a patch tool with a fully documented schema it is largely sufficient.

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 including allowMultiple's unique-match default. The description's phrase '锚点文本块' loosely maps to targetContent but adds no format or matching semantics beyond the schema, so 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 and resource: atomic, anchor-based replacement of text blocks in remote large text files. It implicitly differentiates from the whole-file-overwrite sibling (sftp_write_file) via '杜绝整文件覆写', but does not name an alternative tool 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?

Usage is only implied: target edits to large files without rewriting the whole file. There is no explicit when-to-use versus sftp_write_file/sftp_read_file, and no mention of prerequisites such as needing an existing connection.

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 are provided, so the description carries the full behavioral burden. It discloses the internal mechanism (pure JS in-memory streaming Tar) and implies archive-and-extract semantics, but says nothing about overwrite behavior on the remote, permissions, failure/partial-transfer handling, or auth requirements.

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 spends words on implementation architecture ('纯 JS 内存流式 Tar 架构') that is less actionable for an agent than behavioral facts would be.

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 directory-upload tool with no annotations and no output schema, the description conveys the core mechanism and the schema covers all inputs, but it leaves out overwrite semantics and error/partial-transfer 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 every parameter (localPath, remotePath, connectionId, useGitignore, excludePatterns) is already documented in the schema. The description adds no parameter-level detail beyond noting the batch/directory nature, 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+resource: batch-packaging the entire local directory tree and uploading it to the remote host, then extracting. This clearly distinguishes it from single-file sftp_upload and from sftp_download_dir, though it 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?

There is no guidance on when to use this versus sftp_upload (single file) or other transfer tools, and no exclusions or prerequisites stated. The scope word '整个目录树批量' implies directory-level use but stops short of any explicit when/when-not routing.

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, the description carries the full behavioral burden and does contribute key facts: the execution is stateless and it returns exit code, stdout and stderr. However it says nothing about the side-effecting/destructive nature of arbitrary command execution, the sudo/safety-guard behavior, or the dangerous-command bypass hinted at by the 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 zero filler that states verb, resource, execution model and return contract in one pass. Everything in it 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?

For a complex 10-parameter tool with no annotations and no output schema, the description usefully covers the return contract (exit code/stdout/stderr) which compensates for the missing output schema. It is still thin on behavioral caveats for such a powerful, side-effecting tool, leaving it only minimum-viable.

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 ten parameters in detail (cwd wrapping, sudo, dryRun, timeoutMs, rawExec, etc.). The description adds no parameter-level meaning 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 names a specific verb (执行/execute) and resource (single stateless Bash/Shell command on a remote Linux host), and the word '无状态' (stateless) subtly separates it from session/job siblings. It stops short of naming an actual sibling like ssh_session_send or ssh_job_start, so differentiation is implied rather than explicit.

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: '单次无状态' (single, stateless) signals this is for one-off commands rather than persistent sessions, which hints at when it applies versus ssh_session_send or ssh_job_start. There is no explicit when-to-use/when-not statement or named alternative.

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 one genuinely useful behavior: a built-in idle timeout that auto-releases the tunnel to prevent leaks. However, it omits other key behaviors such as the SSH-connection prerequisite, failure/auth semantics, and what identifying handle the created tunnel 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 dense sentence that front-loads the action (建立...隧道) and the mechanism (-L), then appends the leak-prevention behavior in parenthesis. 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?

No annotations and no output schema exist, so the description should carry more. It covers the core action and one behavioral trait, but omits prerequisites (existing SSH connection) and what the tool returns (a tunnel identifier usable with ssh_tunnel_list/ssh_tunnel_close), leaving gaps for a 7-parameter 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%, so every parameter (type, localHost, localPort, remoteHost, remotePort, connectionId, idleTimeoutSeconds) is already explained in the schema. The description adds no parameter-level detail beyond what the schema provides, so the 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 gives a specific verb+resource (建立端口转发隧道) and even names the equivalent SSH flag (-L), so an agent immediately knows this creates a forwarding tunnel. It is somewhat narrowed to local/-L mode even though the schema supports local/remote/socks5, and it does not distinguish itself from the ssh_tunnel_list/ssh_tunnel_close siblings.

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 guidance on when to use this tool versus alternatives, nor any stated prerequisites such as needing an existing SSH connection. The relationship to ssh_tunnel_list and ssh_tunnel_close (how to inspect or tear down the tunnel created here) is left entirely 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. It usefully discloses what gets removed (finished or expired job workspaces) and where (~/.mcp_jobs/), but does not state irreversibility, that deletion is physical, or any permission requirements — the '物理删除' detail lives only in the 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 compact sentence that front-loads the action and its scope, with the target path appended. No wasted clauses, though it is terse enough to leave behavioral gaps.

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, zero-required-parameter destructive tool with no annotations and no output schema, the description covers purpose and target directory but omits irreversibility and permission context, leaving meaningful 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 three parameters are already well documented (jobId targeting, maxAgeDays threshold with default 7, connectionId defaulting to current). The description adds no parameter-level detail beyond that baseline.

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?

Specific verb (清理) plus resource (后台作业工作空间目录) and scope (已结束或过期), with the concrete location ~/.mcp_jobs/ named. It is distinguishable from ssh_job_kill and ssh_job_status, though it does not explicitly reference those siblings.

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 states no when-to-use conditions or alternatives. The choice between targeted cleanup (jobId) and bulk expiry cleanup is only visible in the schema, not in the description. No exclusions or prerequisites 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 must carry the full behavioral burden. It mentions the signal types but omits critical traits: whether the operation is destructive/irreversible, what permissions or connection state are required, and what happens if the job is already gone. This is a kill tool, yet the description does not convey its destructive nature.

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 zero waste. It states the core action and the signal examples immediately, which is appropriately sized for a simple kill 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?

With no annotations and no output schema, the description is expected to fill behavioral gaps. It does not address destructive nature, prerequisites, or when to choose this over ssh_job_clean. Parameter semantics are fully covered by the schema, so the description is adequate but incomplete for safe invocation.

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 jobId, signal, and connectionId thoroughly, including the default SIGTERM. The description repeats the signal example but adds no new meaning 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?

The description states a specific verb (发送终止信号) and resource (远程脱机后台作业进程), making the tool's action immediately clear. It does not explicitly differentiate itself from siblings like ssh_job_clean or ssh_job_status, so it falls short of the top score that requires 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?

The description provides no guidance on when to use this tool versus alternatives such as ssh_job_clean or ssh_job_status. It only states the action, leaving the agent to infer that this is for terminating rather than cleaning or inspecting jobs.

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 usefully discloses that it retrieves both stdout and stderr and that reads can be segmented/incremental, implying a read-only, non-destructive operation. However, it says nothing about auth/permission needs, behavior on a missing or still-running job, or whether log availability depends on job retention.

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 with no filler or repetition. It is appropriately terse, though the fragmentary phrasing offers no structural signposting for the reading/pagination model it hints at.

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 annotations and no output schema, the description is minimal: it identifies what is retrieved but not the return shape, ordering, or failure semantics an agent would want. The 100% schema coverage covers inputs, so the gap is mainly behavioral rather than fatal.

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 jobId, maxLines, offsetLines, and connectionId are all documented in the schema. The description's 分段/增量 wording loosely corresponds to the maxLines/offsetLines paging parameters but adds no syntax, units, or edge-case 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?

The description gives a specific verb (获取) and resource (远程脱机后台作业的标准输出与错误日志), making it clear this reads a detached background job's stdout/stderr. It is distinguishable from job-control siblings like ssh_job_status, ssh_job_start, or ssh_job_kill, though it does not name them.

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?

Phrases like 分段或增量获取 imply the intended usage pattern (paged/incremental log tailing), but there is no explicit when-to-use or when-not-to-use guidance, and no mention of the obvious alternatives (ssh_job_status for state, sftp_read_file for arbitrary files). Usage must be 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?

No annotations, so the description carries full burden. It usefully discloses that the job survives network disconnects and MCP request timeouts, which is key behavioral context. But it omits how the started job is identified (job id) and what is required to manage it, leaving a meaningful gap for a job-lifecycle tool.

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 that leads with the core action and qualifies it with the timeout-immunity benefit. No filler, though it is dense parenthetical framing rather than cleanly separated clauses.

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 no annotations, the description should tell the agent how to follow up (obtaining a job id to use with ssh_job_status/logs/kill). It captures the purpose and key resilience trait but stops short of the lifecycle context an agent needs to actually complete a background-job workflow.

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 (command, cwd, env, connectionId) are already documented in the schema. The description adds only the concept of a long-running command and no format, precedence, or connection-fallback nuance beyond what the schema provides. 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?

States a specific verb+resource (start long-running commands in the background, offline/daemonized on a remote host) and gives concrete examples (compilation, image build, backup). The 'long-running/background/offline' framing implicitly contrasts with ssh_exec, but no sibling is named explicitly, so an agent must infer the distinction.

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 'long-running commands' and the timeout-immunity note, which is enough to signal this is for heavy jobs rather than quick commands. However, it never says when to prefer ssh_exec, nor does it mention the companion lifecycle tools (ssh_job_status, ssh_job_logs, ssh_job_kill) that an agent must use next.

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 conveys that this is a read/query operation returning status codes and execution info, but says nothing about polling behavior, freshness of the data, permission requirements, or behavior when the job no longer exists.

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 listing exactly what is returned. No wasted words, though it is terse enough that it leaves behavioral questions unanswered.

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 the work of naming the return values (liveness, exit code, execution info), which is the key thing an agent needs. Remaining gaps (error behavior, staleness) are minor for a simple status-query 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 only 2 parameters (jobId, connectionId), both documented in the schema itself. The description adds no additional meaning about parameter formats or defaults, 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 uses a specific verb (查询) with a clearly scoped resource (远程脱机后台作业) and enumerates the returned data (存活状态、退出码、执行信息). This distinguishes it from siblings like ssh_job_logs, ssh_job_start, and ssh_job_kill, though the differentiation is implicit rather than stated.

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 purpose implies when the tool is useful (checking on a background job), but it never explicitly says when to use this versus ssh_job_logs for output or ssh_job_kill for termination. Usage is left 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 are provided, so the description carries the full behavioral burden. It usefully discloses the data source (~/.ssh/config, local file) and that it is a read-style listing, but says nothing about behavior when the file is missing/unparseable or how results are shaped. Adequate 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 sentence, front-loaded with the [Deprecated] flag so the most decision-relevant information comes first, followed by scope and then the alternative. No wasted text.

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 deprecated, zero-parameter, read-only listing tool with no output schema, the essentials are covered: source, scope, and the recommended replacement. The one gap is that '基本配置' (basic config) is not itemized, so the exact fields returned remain vague.

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 baseline for a no-param tool is 4. The description correctly implies no filtering or scope arguments are accepted.

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 (读取并列出 / read and list) and a precise resource (Host aliases and basic config parsed from local ~/.ssh/config). It also names the sibling it overlaps with (ssh_list_targets), so an agent can distinguish the two without opening either 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?

Explicitly marks itself as [Deprecated] and routes the agent to a named alternative (ssh_list_targets), described as more comprehensive. This is a clear when-not-to-use signal plus a concrete substitute, matching the strongest calibration example.

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 deprecation status and hints at scope (live connections only, plus default route state), which is valuable behavioral context, but it does not state whether this is a pure read, what the return shape is, or any auth requirements.

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 sentence with the deprecation warning front-loaded, followed immediately by the resource scope and the recommended alternative. 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 deprecated, no-parameter list tool with no output schema, the description supplies the essential routing information. The only minor gap is that it doesn't clarify how its output differs from ssh_list_targets beyond the 'more comprehensive' framing.

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 the baseline is 4. The description correctly implies there are no inputs to specify and adds no misleading parameter 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 (列出/list) plus two concrete resources (存活的 SSH 连接 and 默认路由状态), so the scope is unambiguous. It also names the sibling ssh_list_targets as the preferred replacement, letting an agent distinguish this tool 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?

Explicitly marks the tool as deprecated and directs the agent to ssh_list_targets as a more comprehensive alternative. This is exactly the when-not-to-use and alternative-routing guidance the dimension asks for.

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 does disclose the two data sources (live connected nodes and local ~/.ssh/config presets), which is genuinely useful context, but says nothing about read-only safety, deduplication between the two sources, ordering, or freshness of the config file read.

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 dense sentence, front-loaded with the framing ('统一目标发现视图') followed by the two aggregated sources. No wasted words, though the colon-heavy Chinese phrasing packs a lot into one clause.

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 exists, so the description must describe returns — and it does name the two components of the aggregate (active connected nodes, local config hosts). It stops short of describing the merge/return structure or duplicate handling, but is adequate for a zero-parameter read 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?

The tool takes zero parameters, so the schema leaves nothing to explain; baseline 4 applies. There is no input the description could clarify further.

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 (聚合返回 / aggregate-and-return) and resource (统一目标发现视图 of connected nodes plus ~/.ssh/config hosts). An agent can tell this is a combined view rather than a single-source list, though it never names the siblings ssh_list_connections and ssh_list_config_hosts that it supersedes.

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: the '一次性聚合' (one-shot aggregation) phrasing hints this should be preferred over calling the two narrower list tools separately, but no explicit when-to-use, when-not-to-use, or alternative is stated. Nothing tells the agent whether this replaces or supplements ssh_list_connections.

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 exist, so the description carries the full burden; it does disclose the core behavior of writing input and gathering incremental screen echo, which is useful. However it omits blocking semantics, whether writes mutate persistent session state, and any permission requirements — significant gaps for an interactive write 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 dense sentence with the action front-loaded and no filler; the parenthetical control-character example is directly useful. Slightly compressed for the number of behaviors it touches, but well-structured.

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 5 parameters, no annotations, and no output schema, the description is adequate but lean. It covers the input/echo loop yet leaves out how the call blocks, when it returns, and how it relates to sibling session/exec tools, leaving clear gaps for a fairly complex interactive 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%, so the schema already documents sessionId, input, timeoutMs, waitForMs, and expectPattern. The description's Ctrl+C example duplicates the schema's own input description and adds no new parameter 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?

The description states a specific verb (写入/write) and resource (指定的持久 PTY 终端) plus what it returns (增量屏幕回显), so an agent knows this drives an interactive terminal rather than a one-shot exec. It doesn't explicitly name ssh_exec or ssh_session_start as the contrasting sibling, keeping it below 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, when-not-to-use, or alternative guidance. The agent must infer from the 'persistent PTY' framing that this is for interactive/long-lived sessions rather than ssh_exec, but nothing states that routing rule.

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.

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

No annotations exist, so the description carries the full burden. It usefully declares '无损' (non-destructive), signaling a read-only operation, but omits permission requirements, execution time, failure modes, and return format details. This is better than a plain mutation description but still incomplete for a 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?

The description is a single compact sentence with no filler. It front-loads the action ('一键无损采集') before listing the collected resources, though the dense enumeration is less structured than a multi-sentence breakdown.

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 read-only tool with a fully documented single parameter and no output schema, the description adequately communicates the collected fields, which effectively describe the return content. Minor gaps remain around usage context and exact output format, but no critical information for invocation is missing.

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 documents the sole connectionId parameter (100% coverage), including its default behavior. The description adds no additional syntax or meaning for connectionId beyond what the schema already provides, 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 uses a specific verb '采集' (collect) and resource '远程 Linux 系统的...摘要' (remote Linux system summary), explicitly enumerating the collected data: distro, kernel, architecture, CPU load, memory/disk, and listening ports. This clearly distinguishes it from generic execution siblings like ssh_exec or ssh_ping.

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 or alternatives are provided. It does not state when to prefer this over ssh_exec or other SSH tools, nor does it mention prerequisites like needing an active connection, apart from what the schema implies via connectionId.

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 disclose one meaningful behavioral consequence beyond the name — that the host's local listening port is released — but is silent on what happens if the tunnel is already gone (idempotency), error behavior for an unknown/invalid tunnelId, and any permission requirements.

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 its effect are stated immediately. It is appropriately sized for a one-parameter tool, though it leaves no room for the guidance the previous dimensions flag as missing.

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 and no annotations, the description covers purpose and the port-release effect, which is roughly adequate. It nonetheless omits error/idempotency behavior that an agent needs before calling a mutating close 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% with a single fully documented tunnelId parameter, so the schema already carries the semantics. '按标识符' merely echoes the schema's '待关闭的端口转发隧道 ID' and adds no format, origin, or lookup guidance beyond it; 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?

States a specific verb (关闭/close), a precise resource (端口转发隧道/port forwarding tunnel), the identification method (按标识符), and the side effect (释放宿主机本地监听端口). This lets an agent distinguish it from the forward-creating sibling ssh_forward_port and the read-only ssh_tunnel_list without opening either 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 says only what the tool does; it gives no when-to-use context, no prerequisites, and no routing against alternatives such as ssh_disconnect or ssh_session_close that could plausibly overlap. Usage is left entirely to inference from 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 behavioral burden. '列出' plus '当前所有活跃的' does communicate that this is a non-mutating read scoped to active tunnels, which rules out any write side effect. However, it does not say whether authentication is required, whether inactive/closed tunnels are excluded, or whether the tunnel list can be stale, leaving real gaps for an unannotated tool.

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 dense sentence that front-loads the verb and resource with no filler or redundancy. It is appropriately sized for a no-argument listing tool, though the phrase packs listing scope and all three reported fields into one clause.

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 usefully compensates by naming what comes back: tunnel status, port mappings, and transfer statistics. For a parameterless read tool this is close to complete; only the active-vs-inactive filter boundary and any permission requirement remain 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, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema coverage is 100% and the input object is empty, which is fully consistent with the description's claim of listing all active tunnels.

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?

Specific verb (列出/list) plus a precise resource (活跃的端口转发隧道) and an explicit scope of what is reported (状态、端口映射、传输统计). An agent can distinguish it from ssh_list_connections or ssh_list_targets by the resource, though it never names a sibling explicitly to reinforce the contrast.

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 contains no when-to-use or when-not-to-use guidance. It does not tell the agent how this relates to ssh_forward_port (which creates tunnels) or ssh_tunnel_close, nor that it should be called before closing a tunnel to obtain its identifier. Usage must be inferred entirely.

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