Skip to main content
Glama
Sign In
ugreen-nas

ugreen-nas

by xudong7587
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

ugreen_file_stat

Read-onlyIdempotent

Retrieve metadata for a NAS file or directory from a given path, including listing or search result details, to inspect attributes before further file operations.

Instructions

查询一个 NAS 文件/目录的元数据；使用列表或搜索返回的路径。结果在 items[0].data.stat，64 位数值可能是字符串。

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_file_stat"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive semantics, so the description's job is mainly output disclosure. It does that by naming the result location (items[0].data.stat) and warning that 64-bit values may come back as strings — a real precision hazard an agent would otherwise mishandle.

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?

Three compact clauses: purpose, input sourcing, output location with a numeric-type caveat. Nothing is redundant and the purpose is front-loaded.

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 supplies the return-path and the string-encoded-number caveat, which is what an agent needs to parse a response. Minor gaps remain around error behavior for missing paths and permission requirements on an open-world NAS backend.

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 0%, so the description must carry the single path parameter — and it does add source meaning (paths from list/search results). It still says nothing about path formatting (absolute vs relative, leading slash) or what happens when the path does not exist.

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?

The description opens with a specific verb+resource pair ("查询一个 NAS 文件/目录的元数据"), which clearly separates it from content tools like ugreen_read_file and from listing tools. It does not explicitly name what it is not, but the metadata framing is unambiguous.

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?

"使用列表或搜索返回的路径" tells the agent where a valid path must come from, which implicitly routes it through ugreen_list_files / ugreen_search first. There is no explicit when-not guidance, such as preferring ugreen_read_file when file contents are needed.

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