Skip to main content
Glama
Sign In
ugreen-nas

ugreen-nas

by xudong7587
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

ugreen_execute

Destructive

Runs official UGREEN NAS CLI commands to manage files, apps, Docker containers, users, downloads, storage, and system tasks. Query help first, use dry_run for risky writes, then execute.

Instructions

执行官方 unc 的完整 NAS 业务命令，权限由现有令牌和 NAS 固件决定。command 选择叶命令路径，arguments 是独立参数数组，不要包含 unc、命令路径或 shell 语法。先查询帮助和目标对象，再按用户授权操作；删除、覆盖、服务变更等先 dry_run 预演。需要确认门禁时显式传 --yes，已有授权无需重复询问。dry_run 默认 false；预演可能联网，成功不保证真实执行成功。流式请求最多 1800 秒；写操作超时或失败后先查状态，不自动重试。stdin 为 UTF-8 内容，创建用户仅用 --password-stdin 与 stdin 传密码。认证覆盖、输出重定向、调试和 CLI 本机管理命令不可用。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "ugreen_execute"
  }
}

Input Schema

NameRequiredDescriptionDefault
stdinNo
commandYes
dry_runNo
argumentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.2/5.0
Behavior5/5

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

Far exceeds the annotations (destructive, non-idempotent, open-world) by explaining that dry_run defaults to false, that a dry run may hit the network and a successful rehearsal does not guarantee successful real execution, that streaming requests can last up to 1800 seconds, and that writes failing or timing out require a status check rather than a retry. It also enumerates what is NOT available (auth coverage, output redirection, debug, local CLI management commands) and the --yes confirmation gate. This is exactly the behavioral context annotations cannot convey.

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 what the tool is, then moves through command/arguments/stdin/dry_run semantics and finally operational cautions. Dense but nearly every sentence carries actionable information; the only soft spot is a couple of terse clauses (unsupported feature list) that assume CLI familiarity.

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 100-command dispatcher with a 0%-documented schema and no output schema, the description covers the essentials an agent needs to invoke it safely: required help-first workflow, dry_run semantics and its limits, timeout handling for writes, stdin usage, and unsupported capabilities. Return/output format is left unspecified, which is acceptable given the tool delegates detail to help lookups but leaves the agent without expectations about response shape.

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 description coverage is 0%, so the description must carry the load, and it does: command selects a leaf command path, arguments is a standalone string array that must not include 'unc', the command path, or shell syntax, stdin is UTF-8 content used for --password-stdin during user creation, and dry_run defaults to false with network implications. It does not describe per-command argument syntax, though that is explicitly delegated to the help lookup, which is a reasonable division of labor for a 100-value enum.

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?

Names a specific verb and resource: it executes the full set of official 'unc' NAS business commands, with permissions bounded by the existing token and NAS firmware. The dispatcher nature is clear, but it never states how it relates to the dedicated siblings (ugreen_read_file, ugreen_delete_file, ugreen_move_file, etc.), so an agent must infer that the narrow tools are preferred for routine file work.

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?

Gives concrete operating procedure: look up help and the target object first, act within user authorization, and dry_run before deletions, overwrites, or service changes; pass --yes only when a confirmation gate applies and don't re-ask when authorization already exists. It also tells the agent not to auto-retry writes after timeout/failure but to check status first. What is missing is an explicit statement of when to prefer the specialized sibling tools over this general executor.

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