Skip to main content
Glama
sangingeum
by sangingeum

file_copy

Destructive

Copies one file inside a workspace, returns an operation ID for undo, and blocks occupied destinations unless the expected hash matches.

Instructions

Copy one file inside the workspace and return operation_id and undo_available.

    An occupied destination is refused unless expected_destination_hash
    matches its current content. The copy is not atomic across its two paths,
    but it is recorded as one operation, so undo restores both ends. The
    destination is subject to the credential-shaped refusal. dry_run writes
    nothing. Otherwise the operation is undoable.
    

Input Schema

NameRequiredDescriptionDefault
sourceYes
dry_runNo
destinationYes
expected_destination_hashNo
i_accept_secret_write_riskNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses non-atomicity across the two paths, that it is recorded as a single undoable operation restoring both ends, the credential-shaped refusal, and that dry_run writes nothing. These are exactly the risk details an agent needs for a destructiveHint=true mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose and return values, followed by tight behavioral clauses that each add information. Mild deduction for the jargon 'credential-shaped refusal', which is dense and not immediately parseable without the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description names the returns (operation_id, undo_available) and covers atomicity, idempotent-ish destination guarding, and undo semantics. Only gap is the un-named secret-write parameter, which prevents a 5.

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

Parameters3/5

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

With 0% schema description coverage the description must carry the load, and it does explain expected_destination_hash (must match current content) and dry_run. However, source is unstated and i_accept_secret_write_risk is only alluded to obliquely as 'the credential-shaped refusal' rather than named, leaving two of five parameters under-specified.

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

Purpose4/5

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

Opening sentence gives a specific verb and resource ('Copy one file inside the workspace') plus the return values, which lets an agent separate it from file_move/file_write. It stops short of explicitly contrasting with the copy-adjacent siblings, so it lands 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.

Usage Guidelines3/5

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

The description is explicit about conditional behavior (occupied destination refused unless expected_destination_hash matches; dry_run writes nothing), which implies when to use those flags. But it never states when to prefer file_copy over file_move or explains the i_accept_secret_write_risk escape hatch, so guidance is implied rather than complete.

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