Skip to main content
Glama
Sign In
mcp-synology

mcp-synology

by cmeans
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

upload_file

Destructive

Upload one local file to a Synology NAS folder. Choose a destination folder, optionally create missing parents, and control whether an existing file of the same name is replaced.

Instructions

Upload one file from this machine (where this server runs) to a NAS folder; a local folder can't be uploaded. An existing NAS file of the same name is not replaced unless overwrite is true.

Input Schema

NameRequiredDescriptionDefault
filenameNoName for the file on the NAS (default: the local file's name).
overwriteNoReplace a NAS file of the same name (default false: the call fails and the NAS file is kept).
local_pathYesThe file on this machine, inside one of the allowed local folders (/root/Downloads), or below it.
dest_folderNoNAS folder to upload into (`/video/Uploads`). Optional when a default upload folder is configured.
create_parentsNoCreate `dest_folder` and any missing folders above it (default true); with `false`, `dest_folder` must already exist.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.9.1
    • addedInput schema / properties / create_parents / description
      Added value: +"Create `dest_folder` and any missing folders above it (default true); with `false`, `dest_folder` must already exist."
    • addedInput schema / properties / dest_folder / description
      Added value: +"NAS folder to upload into (`/video/Uploads`). Optional when a default upload folder is configured."
    • addedInput schema / properties / filename / description
      Added value: +"Name for the file on the NAS (default: the local file's name)."
    • addedInput schema / properties / local_path / description
      Added value: +"The file on this machine, inside one of the allowed local folders (/root/Downloads), or below it."
    • addedInput schema / properties / overwrite / description
      Added value: +"Replace a NAS file of the same name (default false: the call fails and the NAS file is kept)."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "tool_upload_fileOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.7.1

TDQS

A3.8/5.0
Behavior4/5

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

The annotations mark this as non-read-only and potentially destructive, and the description usefully clarifies the key destructive behavior: an existing NAS file of the same name is kept unless overwrite is true. This adds important safety context beyond the annotations. It does not discuss permissions or return behavior, but the overwrite semantics are well covered.

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?

The description is short, front-loaded with the core action, and contains no filler. The semicolon cleanly introduces the two most important constraints: single-file scope and default non-overwrite behavior.

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?

Given the 100% schema coverage and annotations, the description is nearly complete for an upload tool: it explains the source/destination relationship, single-file limitation, and overwrite safety default. It could be slightly stronger by mentioning that dest_folder creation is controlled by create_parents or by naming an alternative for folder uploads, but those gaps are minor.

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 the schema already documents all five parameters, including overwrite, dest_folder, and create_parents. The description adds the single-file constraint and reinforces the overwrite default, but it does not add substantial meaning beyond the schema for most parameters.

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

Purpose4/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: upload one file from the local machine to a NAS folder. It also clarifies the scope by saying a local folder cannot be uploaded, which helps distinguish it from folder-oriented operations. It is clear but does not explicitly differentiate against sibling upload/download/file-management tools.

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

Usage Guidelines3/5

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

The description gives useful context that this tool uploads a single file and cannot upload a local folder, and it explains the default overwrite behavior. However, it does not say when to use this vs siblings such as copy_files, move_files, or download_file, nor does it name an alternative tool for folder uploads.

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