Skip to main content
Glama
Sign In
mcp-synology

mcp-synology

by cmeans
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

download_file

Destructive

Download a NAS file or folder to a local folder, with folders saved as ZIP archives. Choose a destination folder and optionally overwrite existing local files.

Instructions

Download a NAS file to a folder on this machine (where this server runs). A folder downloads as a ZIP of it, saved as <folder>.zip; a whole shared folder can't be downloaded. An existing local file is not replaced unless overwrite is true.

Input Schema

NameRequiredDescriptionDefault
pathYesThe NAS file or folder (`/video/Movies/Dune.mkv`).
filenameNoName to save as, a plain file name with no folders (default: the NAS name, or `<folder>.zip` for a folder).
overwriteNoReplace a local file of the same name (default false: the call fails and the local file is kept).
dest_folderNoLocal folder to save into: one of the allowed local folders (/root/Downloads), or a folder below it. Optional when a default download folder is configured.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.9.1
    • addedInput schema / properties / dest_folder / description
      Added value: +"Local folder to save into: one of the allowed local folders (/root/Downloads), or a folder below it. Optional when a default download folder is configured."
    • addedInput schema / properties / filename / description
      Added value: +"Name to save as, a plain file name with no folders (default: the NAS name, or `<folder>.zip` for a folder)."
    • addedInput schema / properties / overwrite / description
      Added value: +"Replace a local file of the same name (default false: the call fails and the local file is kept)."
    • addedInput schema / properties / path / description
      Added value: +"The NAS file or folder (`/video/Movies/Dune.mkv`)."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "tool_download_fileOutput",
-  "type": "object"
-}New value: +null
  2. Changed11 schema fields changedv0.7.0
    • removedInput schema / properties / dest_folder / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / dest_folder / default
      Removed value: -null
    • removedInput schema / properties / dest_folder / title
      Removed value: -"Dest Folder"
    • addedInput schema / properties / dest_folder / type
      Added value: +"string"
    • removedInput schema / properties / filename / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / filename / default
      Removed value: -null
    • removedInput schema / properties / filename / title
      Removed value: -"Filename"
    • addedInput schema / properties / filename / type
      Added value: +"string"
    • removedInput schema / properties / overwrite / title
      Removed value: -"Overwrite"
    • removedInput schema / properties / path / title
      Removed value: -"Path"
    • removedInput schema / title
      Removed value: -"tool_download_fileArguments"
  3. First observedv0.4.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description earns credit by explaining exactly what gets destroyed and when: an existing local file is kept and the call fails unless `overwrite` is true. It doesn't cover other behavior an agent might need, such as whether the call blocks until the transfer completes or what is returned (no output schema exists).

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?

Three tight sentences: the core action first, then folder/zip semantics and the shared-folder restriction, then the overwrite caveat. No padding.

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 4-parameter tool with no output schema, the description covers the destructive path and the notable edge cases well. It leaves out the return value (presumably the saved local path) and any indication of long-running/large-transfer behavior, which matters for a NAS download.

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?

Schema coverage is 100%, so `filename`, `overwrite`, `dest_folder` and `path` are all documented in the schema already. The description restates the overwrite default and the zip naming rule but adds no semantics beyond the schema — baseline 3 is appropriate.

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 plus the destination ('Download a NAS file to a folder on this machine (where this server runs)'), which separates it from the download-station style siblings like create_download. It also defines the scope precisely: a folder becomes a ZIP, a whole shared folder is not allowed.

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?

The description gives concrete conditions that govern use — folder downloads produce `<folder>.zip`, shared folders can't be downloaded, and existing local files block the call unless `overwrite` is set. It never explicitly names an alternative sibling (e.g. create_download) or when not to use this tool, so it stops short of full routing guidance.

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