Skip to main content
Glama

move

Reorganize your secure vault contents. Move or rename files and folders while maintaining data integrity. All changes are logged and can be fully undone.

Instructions

Move or rename a file or folder (with everything in it) inside one open vault that may be changed. Nothing is overwritten: the new path must be free and its parent folder must exist. Use copy_file to keep the original, or trash to remove something. The change is logged and undo moves it back. Returns the old and new paths and the change id; if the user asked to approve moves, it may instead return a question for them.

Input Schema

NameRequiredDescriptionDefault
toYesThe new path in the same vault, for example 'Archive/2025/notes.md'. It must be free.
pathYesA path inside the vault, from its top, for example 'Taxes/2025/receipts.md'.
vaultYesThe vault's name, as listed by the vaults tool, for example 'Taxes'.
confirmNoLeave empty. Only pass the code a previous answer gave you, after the user agreed.
purposeYesA few words on why, shown to the user or kept in the vault's change log.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.4
    • addedInput schema / properties / confirm / description
      Added value: +"Leave empty. Only pass the code a previous answer gave you, after the user agreed."
    • addedInput schema / properties / path / description
      Added value: +"A path inside the vault, from its top, for example 'Taxes/2025/receipts.md'."
    • addedInput schema / properties / purpose / description
      Added value: +"A few words on why, shown to the user or kept in the vault's change log."
    • addedInput schema / properties / to / description
      Added value: +"The new path in the same vault, for example 'Archive/2025/notes.md'. It must be free."
    • addedInput schema / properties / vault / description
      Added value: +"The vault's name, as listed by the vaults tool, for example 'Taxes'."
  2. First observedv0.1.3

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: nothing is overwritten, parent must exist, the change is logged, undo reverses it, and an approval flow may replace the normal result with a question. That approval round-trip is behavior an agent cannot learn from readOnly/destructive/idempotent hints alone.

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

Conciseness5/5

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

Front-loads the action and scope, then constraints, then alternatives, then return/approval behavior. Every clause carries information; nothing is redundant with the name or schema.

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

Completeness5/5

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

With an output schema present, return values need not be detailed, yet the description still flags the non-obvious case where a question is returned instead of paths. Combined with annotations on safety and the destructive/undo profile, an agent has everything needed to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so per-parameter explanations already exist and the baseline is 3. The description adds cross-parameter meaning, explaining the two-phase confirm/approval cycle ('if the user asked to approve moves, it may instead return a question') that ties confirm to the response, though it gives no extra syntax for path/to beyond the schema examples.

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?

States a specific verb and resource ('Move or rename a file or folder') plus scope ('inside one open vault', including contained items). It explicitly separates itself from copy_file and trash, so an agent can route correctly without opening sibling schemas.

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

Usage Guidelines5/5

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

Names the alternative tools and the conditions selecting them ('Use copy_file to keep the original, or trash to remove something'), and gives preconditions (new path must be free, parent folder must exist). Nothing about when-to-use is left to inference.

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