Skip to main content
Glama
mcp-synology

mcp-synology

list_shares

Read-only

Lists all top-level shared folders on the NAS so you can discover valid root paths, along with each share's volume, free space, and recycle-bin status.

Instructions

List all shared folders on the NAS: the top-level folders every file path starts with (/video). Call this first to discover paths. Shows each share's volume, that volume's free space (shared by every share on it) and whether its recycle bin is on; for how much space a share uses, call get_dir_size.

Input Schema

NameRequiredDescriptionDefault
sort_byNo`name` (default), `user` (the owner), `mtime` (modified) or `crtime` (created).name
sort_directionNo`asc` (default) or `desc`.asc

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.9.1
    • addedInput schema / properties / sort_by / description
      Added value: +"`name` (default), `user` (the owner), `mtime` (modified) or `crtime` (created)."
    • addedInput schema / properties / sort_direction / description
      Added value: +"`asc` (default) or `desc`."
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "title": "Result",
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "tool_list_sharesOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed1 schema field changedv0.8.0
    • removedInput schema / properties / additional
      Removed value: -{
      -  "items": {
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
  3. Changed4 schema fields changedv0.7.0
    • addedInput schema / properties / additional
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / sort_by / title
      Removed value: -"Sort By"
    • removedInput schema / properties / sort_direction / title
      Removed value: -"Sort Direction"
    • removedInput schema / title
      Removed value: -"tool_list_sharesArguments"
  4. First observedv0.4.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/non-destructive, and the description adds real value beyond them: what each entry contains (volume, recycle-bin flag) and the caveat that free space is per-volume and shared across shares. It stops short of describing pagination or exact return shape, but the behavioral profile is clear.

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-loaded with the core definition and the "call this first" directive before the details; three dense sentences that mostly earn their place, though the free-space parenthetical is slightly compressed.

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?

With no output schema, the description usefully summarizes what is returned (volume, free space, recycle-bin status) and flags the shared-free-space nuance. It omits any mention of the sortable fields or the number/shape of entries, which is a minor gap.

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 sort_by and sort_direction are fully documented in the schema; the description says nothing about sorting. Baseline 3 applies since the schema carries this dimension.

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 ("List all shared folders on the NAS") and adds a concrete definition ("the top-level folders every file path starts with (`/video`)"), which separates it cleanly from siblings like list_files or get_dir_size.

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 says "Call this first to discover paths" and routes the size question to get_dir_size, so both when-to-use and the alternative are stated outright.

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