copy_file

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

The description provides rich behavioral details beyond the annotations: never overwrites, existing destination causes an error, source must be a file, destination parent must exist, paths must be inside allowed directories, and relative paths resolve against the server start directory. These are exactly the kind of non-obvious behaviors an agent needs to know. There is no contradiction with the annotations.

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 dense but every sentence serves a purpose: core semantics, typical use, parameter preconditions, failure behavior, path constraints, and sibling routing. It is front-loaded with the most important information and uses straightforward language without 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?

Given this is a simple two-parameter copy operation with an output schema available, the description covers everything needed for correct invocation: exact behavior, preconditions, error conditions, path constraints, and alternatives. No critical information 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?

With 0% schema description coverage, the description compensates by naming both parameters and clarifying their roles: source is a required file path and destination is a required path whose parent must exist and which must not already exist. It could have described path formats more explicitly, but it adds meaningful semantics beyond the bare string 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 opens with a precise action: 'Copy one file byte for byte, keeping its encoding, BOM, line endings, permissions and mtime.' This clearly identifies the resource and operation, and it distinguishes copy_file from sibling tools by emphasizing its byte-for-byte preservation semantics.

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 explicitly states the primary use case ('back up a file before an edit or a conversion') and names concrete alternatives with selection criteria: prefer move_file to relocate, write_file for new content, and convert_encoding with backup=true for a .bak beside a converted file. This leaves no ambiguity about when to choose this tool.

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