Skip to main content
Glama
Sign In
mcp-synology

mcp-synology

by cmeans
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

move_files

Destructive

Move files or folders into an existing destination folder and remove them from the source; existing destination items are skipped by default unless overwrite is enabled.

Instructions

Move files or folders into a destination folder; a folder moves with everything in it, and the sources are removed. To keep the sources, use copy_files. dest_folder must already exist; it isn't created. With overwrite=false (default), items already at the destination are skipped, listed and left at the source. If any source is missing, nothing is moved. A long move keeps running on the NAS and returns a handle for file_task.

Input Schema

NameRequiredDescriptionDefault
pathsYesFiles or folders to move (`/video/Downloads/clip.mkv`).
overwriteNoReplace items already at the destination (default false: they're skipped and listed).
dest_folderYesThe existing folder to move into (`/video/Archive`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.9.1
    • addedInput schema / properties / dest_folder / description
      Added value: +"The existing folder to move into (`/video/Archive`)."
    • addedInput schema / properties / overwrite / description
      Added value: +"Replace items already at the destination (default false: they're skipped and listed)."
    • addedInput schema / properties / paths / description
      Added value: +"Files or folders to move (`/video/Downloads/clip.mkv`)."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "tool_move_filesOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.7.1

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: annotations only declare destructiveHint=true, while the description spells out that folders move recursively, that overwrite=false skips and lists existing destination items leaving them at source, that a missing source aborts the whole operation, and that long moves continue on the NAS and return a handle for file_task. These are the exact behaviors an agent needs before invoking a destructive operation.

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?

Five short clauses, front-loaded with the core action and destruction consequence, then the alternative, then preconditions and edge cases. No sentence repeats the name or title and none could be dropped without losing a decision-relevant fact.

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?

For a 3-parameter destructive tool with no output schema, the description covers the mutation effect, prerequisite state, partial-failure semantics, and the async escape hatch to file_task. Nothing an agent needs in order to call it safely is missing.

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 the baseline is 3, but the description adds meaning the schema lacks: the all-or-nothing atomicity tied to `paths` ('if any source is missing, nothing is moved') and the fact that skipped items remain at the source under `overwrite=false`. It largely restates the `dest_folder` existence requirement already in the schema, keeping it short of a 5.

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 files or folders into a destination folder) and immediately distinguishes the semantics from the closest sibling by noting that sources are removed and pointing to copy_files for the non-destructive variant. An agent can pick this over copy_files without inspecting either schema.

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?

Explicitly names the alternative (copy_files) and the condition that selects it ('to keep the sources'). It also gives preconditions ('dest_folder must already exist; it isn't created') and the default-mode behavior, so both use and non-use are covered.

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

Deploy Server

Other Tools