Download a file from WSL

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds value beyond that: the local path is resolved on the Windows side and printed back ('check it'), and certain sensitive local locations are refused — behavioral facts the annotations do not convey.

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?

Three short sentences, front-loaded with the core action, then the caveats. Every sentence carries a distinct point (what it does, path resolution, refusal constraints) with no 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?

No output schema exists, but the description notes the resolved local path is printed in the reply and flags the two main failure conditions (missing directory, refused locations), which is sufficient to call the tool correctly. The remaining gap is sibling discrimination rather than call mechanics.

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 all three parameters documented, so the baseline is 3. The description reinforces that localPath is resolved/printed on the Windows side but adds no syntax, format, or edge-case detail beyond what the schema already provides.

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 with direction ('Copy a file from the distro to this machine'), which is enough to separate it from the reverse-direction sibling wsl_upload. It stops short of naming wsl_upload or wsl_read_file explicitly as the alternative, 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?

The description supplies real preconditions — the destination directory must already exist and credential/MCP config locations on the local side are refused — which tells the agent when the call will fail. However, it never says when to prefer this over wsl_read_file (reading content inline) or how it relates to wsl_upload, leaving the main sibling-selection decision to inference.

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