Skip to main content
Glama
sangingeum
by sangingeum

file_move

Destructive

Move or rename a workspace file with overwrite protection and undo support; use dry_run to preview and undo to restore both source and destination.

Instructions

Move or rename one file inside the workspace and return operation_id and undo_available.

    An occupied destination is refused unless overwrite is true, which makes
    the call destructive at the destination. The move is recorded as one
    operation and undo restores both ends. Credential-shaped destinations are
    refused. dry_run writes nothing. Otherwise the operation is undoable.
    

Input Schema

NameRequiredDescriptionDefault
sourceYes
dry_runNo
overwriteNo
destinationYes
i_accept_secret_write_riskNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.3/5.0
Behavior5/5

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

The description adds substantial context beyond the destructiveHint annotation: overwrite makes the call destructive only at the destination, undo restores both ends, the move is recorded as one operation, credential-shaped destinations are refused, and dry_run writes nothing.

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?

The description is front-loaded and appropriately short, with the main behavior and constraints stated up front. There is minor redundancy between "undo restores both ends" and "Otherwise the operation is undoable," but it remains efficient.

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?

For a tool with no output schema, the description helpfully states the return fields operation_id and undo_available and covers the main mutation risks. It is not fully complete because the i_accept_secret_write_risk parameter and its interaction with the credential-destination refusal are left unexplained.

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 usefully explains overwrite, dry_run, and the source/destination purpose. However, it does not explain i_accept_secret_write_risk at all, and it gives no path-format guidance, so it only partially compensates for the schema gap.

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

Purpose5/5

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

The description states a specific verb and resource: "Move or rename one file inside the workspace." It also names the return values, which makes the tool clearly distinguishable from copy/delete siblings.

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

Usage Guidelines4/5

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

It gives clear usage conditions and exclusions: occupied destinations are refused unless overwrite is true, credential-shaped destinations are refused, and dry_run writes nothing. It does not explicitly name alternatives such as file_copy for copying, so it stops short of the top score.

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