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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: the confirm flag must be explicitly true at runtime, and deletion is limited to files and empty directories. It stops short of describing failure behavior or irreversibility.

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 a semicolon clause; the destructive scope is front-loaded and the confirm gate follows. 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?

An output schema exists, so return values need not be explained, and annotations carry the safety hints. The description plus schema covers path, server, and the confirm gate adequately; only failure/error behavior and permission expectations are 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?

Schema description coverage is 100% — path, server, and confirm are all documented, including confirm's runtime requirement. The description restates the confirm constraint rather than adding new semantics, so the schema does the heavy lifting and 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 concrete verb+resource (delete a single file or empty directory) and adds a scope restriction that matters — non-empty directories are out of scope. It does not, however, distinguish itself from siblings such as move or rename, so an agent must infer the boundary from the operation name alone.

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 scope clause (single file or empty dir), which is useful guidance, but there is no explicit when-to-use/when-not statement and no named alternative for removing non-empty trees or relocating content. 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?

Adds real behavior beyond the annotations: recursion, a random staging destination, per-item skip/failure reporting, and explicitly unlimited file count and byte size. This last point is a meaningful warning absent from the structured fields. It still omits overwrite behavior and retry semantics, keeping it short of a 5.

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 core action front-loaded and the limits clause last. Every clause carries information, though the semicolon-separated run-on is slightly heavy.

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 an output schema present, return values need not be explained, and the annotations already declare the safety profile. The description covers recursion, staging target, reporting, and limits — enough for correct invocation, with only minor gaps like overwrite/conflict 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%, so both parameters (server, remote_path) are already documented in the schema. The description adds no path syntax or alias details, 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 (目录) and adds the destination (随机 staging), so an agent can distinguish it from download_file. It does not explicitly name the sibling it contrasts with, but the directory-level scope 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?

Usage is only implied: the phrase '递归' and '不限制文件数量或总字节' hints this is for bulk directory fetches rather than single files, but there is no explicit when-to-use statement or reference to download_file as the 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: the file lands in a random local staging directory (non-deterministic destination) and its size is verified against a known value, which an agent needs to know to locate and trust the result.

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 no filler, front-loading the action, the target, the destination, and the post-condition. Every clause carries information.

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 an output schema present, return values need not be explained, and the two parameters are fully covered by the schema. The description supplies the missing operational context (staging destination and size verification); only error/failure handling is absent, which is a minor 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 both parameters (server, remote_path) are already fully documented in the schema, establishing a baseline of 3. The description adds nothing about parameter semantics, and its mention of 已知大小 does not map to any schema field.

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

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

The description states a specific verb (下载) and resource (单个远程文件) plus the destination (本机随机 staging 目录) and a validation step (校验已知大小). The word 单个 implicitly contrasts with the sibling download_dir for directories, though it never names that 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 explicit guidance on when to use this tool versus read_text_preview, get_file_info, or download_dir, nor any stated prerequisites. Usage is only inferable from the description of what the tool does.

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

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

Annotations carry the safety profile, but readOnlyHint=false sits awkwardly against a description that reads as a pure query — an agent cannot tell whether the call has side effects. The description adds no behavioral context such as error behavior for missing paths, permission requirements, or remote transport/auth implications implied by openWorldHint=true.

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; the resource and return payload come first. It is efficient, though it is arguably too terse to carry any operational framing.

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?

An output schema exists, so enumerating return fields is redundant rather than necessary, and the low-complexity two-parameter signature is well covered by the schema. What is missing is routing guidance among the many siblings (read_text_preview, list_dir, download_file) and any error/missing-file behavior.

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

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

Schema coverage is 100%: both path (virtual absolute path, root semantics) and the optional server alias are fully documented in the schema. The description adds nothing about parameter format, 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?

States a specific verb (返回) plus a specific resource (单个虚拟远程对象) and enumerates the returned attributes (类型、大小、UTC 修改时间). The word 单个 distinguishes it from the sibling listing tools (list_dir, list_servers), but no sibling is named or contrasted 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 description never says when to call this versus read_text_preview (content) or list_dir (listing). Usage is only inferable from the word 单个. No preconditions 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?

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true) leave a puzzle: why is a listing call not read-only? The description resolves it by disclosing that the first SFTP connection may persist TOFU state, which explains the side effect not captured by the annotations. It stops short of 5 because it says nothing about failure modes (unreachable host, bad path) or whether subsequent calls are side-effect free.

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?

Two tight clauses: purpose first, side-effect caveat second, with no filler. The brevity is efficient, though it verges on under-specification rather than true conciseness given the missing usage context.

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?

An output schema exists, so return values need not be described, and annotations plus the TOFU note cover the safety profile. Still missing for a remote-filesystem tool: behavior on nonexistent paths or unavailable servers, and any explicit non-recursive-vs-recursive distinction relative to sibling listing tools.

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

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

Schema description coverage is 100%, and both parameters (path, server) are fully documented in the schema including the '/' root convention and the default-server fallback. The description adds no parameter-level detail, 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 (列出/list) and resource (虚拟远程目录的下一层条目), and the 'next layer only' wording usefully pins down scope as non-recursive. It does not name or distinguish itself from siblings such as search_files or get_file_info, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus search_files, get_file_info, or download_dir, nor any stated prerequisites or exclusions. Usage must be inferred entirely 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is partly covered. The description still adds non-obvious behavior: it does not connect to the remote, does not read credentials, and does not trigger TOFU — meaningful side-effect exclusions the annotations cannot express.

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 clause-dense sentence. The positive scope ('non-sensitive summaries of available logical servers') is front-loaded, and the three negative guarantees follow compactly. Nothing is redundant or padding.

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?

An output schema exists, so return-value structure need not be restated, and the description correctly focuses on scope and side effects. It is complete enough to call safely, with only the lack of explicit sibling routing as a residual 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?

The tool takes zero parameters and the schema is a closed empty object with 100% coverage, so there is nothing for the description to disambiguate. The baseline for a parameterless tool 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 ('列出可用逻辑服务器'), and narrows the payload to '非敏感摘要', which tells the agent exactly what class of data comes back. It implicitly separates itself from connection-oriented siblings like test_connection by asserting it never connects, though it never names an alternative tool outright.

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: an agent can infer this is the discovery/selection step before operating on a server. There is no explicit 'use this before X' or 'use Y instead when you need connection details' guidance, so routing among siblings rests on 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?

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), lowering the bar. The description does add one genuinely useful behavioral fact beyond them: read-only servers reject the call before connecting. It says nothing about what happens when the directory already exists or about permission errors beyond that.

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, front-loaded with the verb and resource, followed by the one caveat that matters. No filler 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?

An output schema exists and both parameters are fully documented, so return values need not be explained. Purpose and one failure mode are covered; the only gap is guidance on choosing this tool over sibling directory-creating operations.

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

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

Schema description coverage is 100% for both parameters (path and optional server alias), so the schema already carries the semantics. The description adds no path syntax, default-server, or aliasing detail beyond it, 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?

States a specific verb+resource (创建目录) scoped to the virtual remote path, which is concrete enough for an agent to act on. It does not, however, distinguish itself from siblings that also materialize directories (e.g. upload_dir), leaving the routing decision implicit.

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 and no named alternative among the 13 siblings. The clause about read-only servers is a precondition caveat, not usage direction, so the agent gets no help choosing this over upload_dir or list_dir.

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

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

Annotations already declare readOnly=false, destructive=true, and idempotent=false. The description adds that the move stays within one logical server and will not overwrite an existing target, which is valuable behavioral context beyond the structured hints.

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. It states the operation, scope, and key constraint 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?

With a full input schema, an output schema, and rich annotations, the description only needs to add operation-specific constraints, which it does (same server, no overwrite). A minor gap is the lack of sibling routing against rename, but the core operation is adequately covered.

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 explains server, from_path, and to_path. The description adds no parameter-specific meaning beyond what the schema provides, making 3 the correct 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?

The description names a specific verb (移动) and resource (对象), and adds scope (同一逻辑服务器的虚拟路径范围内) plus a constraint (不覆盖已有目标). It does not name or distinguish the sibling rename tool, so it stops short of the top score.

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 when-to-use guidance, no prerequisites, and no comparison to alternatives such as rename. The no-overwrite constraint is behavioral context, not usage 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?

The description describes a read of a remote file prefix (with encoding detection), but the annotations declare readOnlyHint=false. A preview/decode operation is inherently read-only, so the declared write-capability flag directly conflicts with the described behavior and could mislead the agent about 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?

A single compact sentence, front-loading the decoding behavior. However, the trailing 'does not return full connection information' clause is cryptic and does not obviously serve the calling agent.

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?

An output schema exists so return values need not be explained, and the schema documents all three parameters. Still, for a tool with encoding selection, a server alias, and a byte budget, the description is minimal and leaves no usage context beyond the bare action.

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 path, server, and max_bytes semantics (absolute virtual path, default server, byte budget 1–1048576) are already fully documented in the schema. The description adds nothing parameter-specific, 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 (decode) and resource (remote file prefix) with the encodings handled, and the title 'preview text file' anchors the intent. It is distinguishable from the CRUD siblings, but it does not explicitly differentiate itself from adjacent read tools like get_file_info or download_file.

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 statement, no condition for choosing this over download_file / get_file_info, and no mention of prerequisites. The trailing clause about not returning connection info does not route the agent to or away from any 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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — the target is not overwritten — but omits what actually happens on a name collision (error vs. silent failure), permission requirements, and whether directories can be renamed.

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 scope constraint and the non-overwrite clause front-loaded, no filler. It is arguably lean to the point of under-specifying, but nothing is wasted.

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?

An output schema exists, so return values need no explanation. Still, for a mutation tool flagged destructive, the description leaves collision behavior, applicable object types, and permissions unstated, making it minimally viable rather than 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%, so path, server and new_name are already fully documented in the schema. The description adds no format or constraint detail beyond what the schema 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?

States a specific verb (rename) plus the resource (an object) and constrains the scope to the same virtual remote directory, which implicitly separates it from the sibling `move`. It does not name siblings explicitly, so an agent must infer that cross-directory relocation belongs to `move`.

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 scope phrase '在同一虚拟远程目录内' implies when this tool is appropriate versus `move`, and the non-overwrite clause hints at a precondition. However, no alternative tool is named and no explicit when-not guidance or prerequisite (e.g., target must not exist) is stated.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is largely covered; the description usefully adds that traversal is recursive and that symlinks are neither entered nor returned, a real behavioral constraint not in the annotations. However, it does not address the notable readOnlyHint=false for what reads as a pure query, nor limits, ordering, or permission requirements on large trees.

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; the recursive-scope constraint comes before the symlink caveat. It is efficient, though arguably too terse for a three-parameter search tool, which is why it falls short of 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?

An output schema exists, so return-value explanation is unnecessary, and all three parameters are documented. Still missing is what an agent needs for correct invocation on large trees: result limits, ordering, whether path may point at a file, and how the symlink exclusion interacts with matching within a symlinked directory.

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% (path, server, pattern all documented, including that pattern is non-empty and cannot contain path separators). The description's mention of 'filename wildcard' merely restates the pattern parameter and adds no syntax examples, glob dialect, or recursion-depth semantics beyond the schema.

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 (递归搜索, recursively search), resource (文件, files under a virtual remote directory), and matching rule (按文件名通配符, by filename wildcard). It clearly separates itself from a plain listing, but it never names siblings such as list_dir or get_file_info, so an agent must infer the boundary.

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

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

It states the matching mechanism and a symlink exclusion, but gives no guidance on when to prefer this over list_dir, get_file_info, or read_text_preview, and no prerequisites or exclusion conditions. The agent is left to infer usage 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?

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so the description is not carrying the safety burden alone. It adds genuinely non-redundant behavior: the first SFTP connection may persist a TOFU host key, which is exactly the side effect that explains readOnlyHint=false and is not derivable from any structured field.

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?

Two tight clauses: the purpose first, the state-changing caveat second. No filler, no repetition of the name or title, and nothing that could be dropped without loss.

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?

An output schema exists, so return/failure reporting need not be described, and the single optional parameter is fully covered by the schema. Purpose plus the persistence side effect are sufficient for correct invocation; a note on what a failed verification means (error vs status field) would round it out.

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 'server' parameter is already documented in-schema as an optional alias defaulting to the default server. The description adds nothing about the parameter, 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 pair ('验证服务器连接和认证'), so an agent immediately knows this validates connectivity and credentials rather than listing, reading, or modifying anything. It is not confusable with any sibling (list_servers, list_dir, upload_file, etc.), though it never explicitly names an alternative. Clear but not sibling-differentiating.

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: an agent infers this should be run before attempting file operations against an uncertain server. There is no explicit 'use when / do not use when', no mention of when a re-test is warranted (e.g., after an auth or network error), and no alternative check documented. The TOFU caveat is the only guidance-adjacent content.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious context beyond the annotations: ok=true signals only that the workflow finished, and status/failed/indeterminate must be inspected, with no blanket retry on indeterminate. That directly explains the consequence of non-idempotency rather than restating it.

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?

Two tight sentences with zero filler; the purpose is front-loaded and the critical result-checking caveat immediately follows. Every clause carries weight.

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?

An output schema exists, so return-shape explanation is not required, yet the description still supplies the key interpretation rule for that output (status/failed/indeterminate). With full schema coverage and annotations present, only selection guidance vs. siblings 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?

Schema coverage is 100%, and all four parameters (server, overwrite, local_path, remote_path) are documented in the schema itself. The description adds no parameter-level detail, 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 ('逐项上传本地目录'), and the word '逐项' (item by item) distinguishes it from a single-file upload. It does not explicitly name upload_file or download_dir as siblings, so 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?

Guidance is about interpreting results and retry behavior ('结果不确定时不得整体重试'), not about when to choose this tool over upload_file or download_dir. Useful, but it is result-handling advice rather than selection guidance, so usage routing is only implied.

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

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

Annotations declare destructiveHint=true, openWorldHint=true and idempotentHint=false, but the description adds genuine context: the upload is staged through a same-directory temporary object (implying an atomic commit) and overwrites are refused by default. This tells the agent why the operation is non-idempotent and what the safe default is, going beyond the raw hints.

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 safety mechanism front-loaded and the overwrite default trailing. Every clause carries information; nothing is padding.

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 an output schema present and annotations covering the safety profile, the description only needs to add the operational traits it does add (single-file scope, temp-object atomicity, no-overwrite default). It omits nothing critical for invoking the tool, though it could note server-alias 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%, so all four parameters (server, overwrite, local_path, remote_path) are already documented in the schema, including the overwrite default of false. The description restates the overwrite default but adds no new syntax or format detail, 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?

States a specific verb and resource: uploading (提交) a single local file. The qualifier '单个本地文件' implicitly distinguishes it from the sibling upload_dir, which handles directories, so an agent can route correctly 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?

There is no explicit when-to-use guidance, no mention of alternatives (e.g., upload_dir for directories, or how this relates to move/rename), and no prerequisites such as authentication or server selection. '默认拒绝覆盖' is a behavioral default, not usage guidance.

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