Skip to main content
Glama
Sign In
mcp-synology

mcp-synology

by cmeans
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

create_download

Create download tasks from HTTP, FTP, magnet links, or local .torrent/.nzb files, specifying an existing destination folder or using your default Synology Download Station destination.

Instructions

Create one or more download tasks, from URIs or from a local .torrent / .nzb file. destination must be an existing folder, share-relative (DS doesn't create folders; make a new one first with File Station's create_folder when File Station write is enabled, or ask the user to create it in DSM). Omit it to use your default destination (a non-manager who has none must set it first with set_download_config, because DS won't start their tasks until then). Returns the new task IDs when DSM provides them (not for URLs with username / password); long magnet links and URI lists are supported.

Input Schema

NameRequiredDescriptionDefault
uriNoOne or more source URIs, comma-separated: HTTP, HTTPS, FTP, magnet and others. Pass this or `torrent_file_path`, not both.
passwordNoPassword for a protected `uri`; not for torrent files.
usernameNoUser name for a protected `uri`; not for torrent files.
destinationNoExisting folder to download into, share-relative (`video/Torrents`). Omit it to use your default destination.
torrent_file_pathNoPath on this machine to a `.torrent` or `.nzb` file, inside one of the allowed local folders (/root/Downloads), or below it. Pass this or `uri`, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.9.1
    • addedInput schema / properties / destination / description
      Added value: +"Existing folder to download into, share-relative (`video/Torrents`). Omit it to use your default destination."
    • addedInput schema / properties / password / description
      Added value: +"Password for a protected `uri`; not for torrent files."
    • addedInput schema / properties / torrent_file_path / description
      Added value: +"Path on this machine to a `.torrent` or `.nzb` file, inside one of the allowed local folders (/root/Downloads), or below it. Pass this or `uri`, not both."
    • addedInput schema / properties / uri / description
      Added value: +"One or more source URIs, comma-separated: HTTP, HTTPS, FTP, magnet and others. Pass this or `torrent_file_path`, not both."
    • addedInput schema / properties / username / description
      Added value: +"User name for a protected `uri`; not for torrent files."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "tool_create_downloadOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.7.1

TDQS

A4.6/5.0
Behavior5/5

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

With annotations declaring readOnlyHint=false/destructiveHint=false, the description adds substantial context: destination must already exist (DS won't create it), omitting it falls back to default, non-managers must set a default first, and task IDs are returned only in certain cases (not for credentialed URLs). Rich disclosure beyond annotations.

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-loads purpose then constraints. Dense but every clause (folder prerequisite, default fallback, ID-return caveat) carries real information, though the parenthetical nesting is slightly heavy.

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 mutation tool with no output schema, it covers the key operational facts an agent needs: source precedence, destination requirements, and return-value conditions. Nothing essential 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%, but the description still adds meaning: destination is share-relative and must be existing, and the default-destination behavior with the non-manager caveat. Goes beyond the schema on the most consequential parameter.

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 ('Create') and resource ('download tasks') with the two supported source types (URIs or local .torrent/.nzb file). Clearly distinguishable from siblings like delete_download, list_downloads, or edit_download.

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?

Explains the destination prerequisite and routes to create_folder or set_download_config when a folder or default destination is missing. Clear context for use, though it doesn't explicitly contrast with sibling task-creation flows, so not a full 5.

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