Skip to main content
Glama

ugreen_delete_file

DestructiveIdempotent

Deletes a specified NAS file or directory, moving it to the recycle bin by default; use dry_run to verify scope, and enable recursive or permanent deletion only when explicitly required.

Instructions

删除用户指定的一个 NAS 文件或目录,默认移入回收站。recursive 默认为 false;删除目录及其内容必须明确指定 true。permanent 仅在用户明确要求永久删除时使用,永久删除不能恢复。先 dry_run 核对范围;CLI 会保护共享根目录并复核删除结果。回收站路径见 data.receipt.final_path,保存它以便恢复。仅操作用户指定的对象;写操作失败后先查询当前状态,不自动重试。权限由绿联令牌与 NAS 账户决定。

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": {
      "path": "<path>"
    },
    "name": "ugreen_delete_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
dry_runNo
permanentNo
recursiveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds substantial context beyond them: the destructive default is actually recycle-bin move (recoverable), permanent deletion is irreversible, shared root directories are protected by the CLI, and deletion results are re-verified. It also discloses permission dependencies (Ugreen token + NAS account) and recovery-path reporting via data.receipt.final_path, which the annotations do not cover.

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?

Purpose and default behavior are front-loaded, and each subsequent clause addresses a real decision (recursion, permanence, dry run) or operational rule. It is dense and slightly long — the auto-retry and token-permission sentences are somewhat tangential — but every sentence earns a place.

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?

Despite having no output schema, the description tells the agent where the recovery pointer appears (data.receipt.final_path) and to retain it. Combined with failure-handling guidance and consent rules for a destructive operation, an agent has everything needed to call this safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 parameter meaning — and it does: recursive's default and the requirement to set it explicitly for directory trees, permanent's irreversibility and user-consent condition, and dry_run's role as a pre-check. These are semantic consequences the bare schema (types/defaults only) does not convey.

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?

Opens with a specific verb+resource (delete a user-specified NAS file or directory) and immediately states the default behavior (move to recycle bin), which distinguishes it from siblings like ugreen_restore_file or ugreen_move_file. An agent can identify the operation and its default safety posture in one sentence.

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 states when to use each branch: recursive=true only when deleting a directory and its contents, permanent=true only when the user explicitly requests irreversible deletion, and dry_run first to verify scope. It also bounds scope ('only operate on user-specified objects') and names what happens after a write failure (query state, do not auto-retry).

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