Skip to main content
Glama
Sign In
ugreen-nas

ugreen-nas

by xudong7587
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

ugreen_write_file

Destructive

Write UTF-8 content to an existing NAS file using overwrite, append, or byte-offset patch modes. Use dry_run to preview important overwrites before committing.

Instructions

写入一个已存在的 NAS 文件，UTF-8 内容最多 256 KiB。write 覆盖原内容；append 追加；patch 按字节 offset 局部写入。仅 patch 接受 offset；新建文件使用 ugreen_create_file 或上传。先用 dry_run 核对重要覆盖。仅操作用户指定的对象；写操作失败后先查询当前状态，不自动重试。权限由绿联令牌与 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>",
      "content": "<content>"
    },
    "name": "ugreen_write_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNowrite
pathYes
offsetNo
contentYes
dry_runNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already mark this as destructive, non-idempotent, and open-world, but the description adds real context beyond them: the 256 KiB payload ceiling, what write does to existing content, byte-offset semantics for patch, the dry_run safety check, a no-auto-retry failure policy, and that permissions come from the Ugreen token and NAS account. What it omits is the response shape and what dry_run actually returns, so it falls short of a 5.

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 dense but front-loaded: the core operation and size limit come first, then mode semantics, then safety and failure rules. Every clause carries actionable information, with no restating of the tool name or filler.

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 destructive five-parameter write tool with no output schema and zero schema descriptions, the definition covers scope, limits, modes, safety, and permissions adequately. The remaining gap is return-value and dry_run output expectations, which an agent would otherwise have to discover empirically.

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 coverage is 0%, so the description must carry parameter meaning, and it does: mode values and their distinct effects, offset being byte-based and valid only for patch, content as UTF-8 under a 256 KiB limit, and dry_run as a pre-check. This goes well beyond the bare enum and defaults in the schema.

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?

The description opens with a specific verb+resource in Chinese: writing to an existing NAS file, with UTF-8 content capped at 256 KiB. It immediately separates this tool from creation paths by stating that new files go through ugreen_create_file or upload, so an agent can distinguish it from siblings such as ugreen_create_file and ugreen_upload_file without opening their schemas.

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?

It spells out the three modes and their semantics (write/append/patch), notes that only patch accepts offset, and routes new-file creation to other tools. It also gives operational guidance: use dry_run before important overwrites, touch only user-specified objects, and query state after a failure instead of auto-retrying.

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