Prepare Genkai file transfer

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

Annotations mark this as destructive (destructiveHint: true) and not read-only (readOnlyHint: false), but the description says 'Preview', which strongly implies a non-destructive, informational action. This is a direct contradiction. No additional behavioral traits are disclosed, such as whether files are moved/copied, whether overwrite behavior is risky, or how SSH authentication is handled. Score is 1 per the annotation contradiction rule.

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 no filler, front-loading the action and resource. It is easy to read and parse. The brevity, however, comes at the cost of important detail, but the dimension judges whether it is appropriately sized; for a tool with this ambiguity, it is slightly too terse, so not 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?

The tool has five parameters, a destructive hint, and no output schema. The description does not explain return values, side effects, prerequisites, or the meaning of 'Preview' in the context of an actual transfer. It is far from complete for an agent to safely invoke this tool, especially given the destructive potential.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It only vaguely aligns 'upload or download' with the 'direction' enum, but fails to explain the roles of 'source' and 'destination' (e.g., which is local vs. remote), or the effects of 'overwrite' and 'recursive'. With five parameters and no meaningful elaboration, the description does not compensate for the schema's lack of descriptions.

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

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

The description names a specific action ('Preview') and a resource ('SSH-mode upload or download between configured local and remote roots'), which distinguishes it from sibling tools that read/write/search files. However, 'Preview' is ambiguous: it could mean a dry-run or an actual transfer, especially given the destructiveHint annotation. This ambiguity hurts clarity.

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 explicit guidance is given on when to use this tool vs. alternatives like manage_files, write_file, or run_command. It does not mention prerequisites, such as having SSH configured, nor does it explain which direction (upload/download) would be appropriate. The only implicit hint is the 'SSH-mode' qualifier, which is not enough.

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