Skip to main content
Glama
Sign In
mcp-synology

mcp-synology

by cmeans
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

set_schedule

DestructiveIdempotent

Update a Synology Download Station schedule: toggle NAS-wide schedule/eMule, set hourly no/full/limited download modes, and apply speed limits; only supplied parameters change.

Instructions

Set the Download Station schedule; get_schedule shows the current one. All parameters are optional: only what you pass is updated. enabled / emule_enabled toggle whether the schedule applies (DSM lets any Download Station user toggle this NAS-wide flag). schedule_plan is in the NAS's local hours, and download_rate / upload_rate are the limited speed. The plan and rates need a Download Station manager/admin account; if that write is refused, nothing is applied.

Input Schema

NameRequiredDescriptionDefault
enabledNoTurn the schedule on or off, for the whole NAS.
upload_rateNoUpload speed in KB/s for hours marked `2`; `0` means unlimited.
download_rateNoDownload speed in KB/s for hours marked `2`; `0` means unlimited.
emule_enabledNoTurn the eMule schedule on or off, for the whole NAS.
schedule_planNo168 characters, one per hour from Sunday 00:00 to Saturday 23:00 in NAS local time: `0` no download, `1` full speed, `2` limited speed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.9.1
    • addedInput schema / properties / download_rate / description
      Added value: +"Download speed in KB/s for hours marked `2`; `0` means unlimited."
    • addedInput schema / properties / emule_enabled / description
      Added value: +"Turn the eMule schedule on or off, for the whole NAS."
    • addedInput schema / properties / enabled / description
      Added value: +"Turn the schedule on or off, for the whole NAS."
    • addedInput schema / properties / schedule_plan / description
      Added value: +"168 characters, one per hour from Sunday 00:00 to Saturday 23:00 in NAS local time: `0` no download, `1` full speed, `2` limited speed."
    • addedInput schema / properties / upload_rate / description
      Added value: +"Upload speed in KB/s for hours marked `2`; `0` means unlimited."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "tool_set_scheduleOutput",
-  "type": "object"
-}New value: +null
  2. Addedv0.7.1

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: partial-update semantics, NAS-wide scope of the enable flags, local-time interpretation of schedule_plan, and the admin/manager requirement for plan and rate writes. It also discloses that a refused write applies nothing, which is important for a destructive/idempotent mutation.

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 sibling distinction, then packs the remaining sentences with scope, partial-update behavior, time semantics, and permission constraints. There is no filler or redundancy.

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 five-parameter mutation tool with full schema coverage and annotations covering safety traits, the description supplies the remaining operational context: partial update behavior, NAS-wide effects, local-time format implications, and permission failure behavior. 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 already 100%, so parameter definitions carry the baseline. The description still adds useful meaning by tying enabled and emule_enabled to a NAS-wide scope, explaining that plan/rates require elevated permissions, and reinforcing that unspecified parameters are left unchanged.

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 ("Set the Download Station schedule") and immediately distinguishes the read-only sibling by naming get_schedule. An agent can tell exactly what this tool changes versus what the companion tool retrieves.

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?

Explicitly says get_schedule shows the current schedule and clarifies that all parameters are optional so only passed fields are updated. That gives clear usage context, though it does not spell out when-not-to-use scenarios beyond the read/write split with get_schedule.

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