ugreen-nas-mcp

Overview Schema Source Related Servers Discussions Admin

Live load and resource use

nas_performance

Read-only

Reads UGREEN NAS task manager metrics for CPU, GPU, memory, fans, network, disk, volumes, processes and services to diagnose slow performance and inspect resource use.

Instructions

Read the task manager. kind "overview" (default) returns CPU, GPU, memory, fans, network and disk activity in one call and is the right first step for "is the NAS slow". "cpu", "gpu", "mem", "net", "disk" and "volume" return one metric each; in net, disk and volume the entry named "overview" is the total. "processes" and "services" list resource use per process or service; sort by cpu, mem or name (pid for processes only) and top keeps the first N (0 for all). Every value is a single instant: to judge a trend, call again a few seconds later. Mind the units: network and per-process disk rates are bytes per second, whole-disk and volume rates are kilobytes per second, memory is bytes, and most numbers are strings. A temperature of 0 means unreadable. On older task manager versions every kind reports "not available"; do not retry. Processes cannot be ended and services cannot be stopped here.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nas_performance"
  }
}

Input Schema

Name	Required	Description	Default
`top`	No	"processes"/"services" only: keep the first N; 0 = all.
`kind`	No	What to measure.	overview
`sort`	No	"processes"/"services" only: sort key.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses that every value is a single instant requiring a repeat call to judge a trend, that most numbers are returned as strings, that 0 temperature means unreadable, and that this tool cannot end processes or stop services. It also warns that older versions return "not available" for all kinds, which prevents pointless retries. That is substantial behavioral context the annotations do not carry.

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?

It is front-loaded with the default and recommended path, then moves to per-kind behavior, then units and caveats. Nearly every sentence carries distinct information, though the density of unit and type caveats makes it heavier than an ideal one-glance definition.

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?

With no output schema, the description carries the return-value burden and does so: it explains the shape per kind, the unit conventions (bytes/sec for network and per-process disk, KB/sec for whole-disk and volume, bytes for memory), the string typing, and the unreadable-temperature sentinel. Little an agent needs to call this correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: in net, disk and volume the entry named "overview" is the total, pid sorting applies only to processes, and top=0 means all. These are semantic clarifications rather than restatements of the field docs.

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 gives a concrete verb and resource ("Read the task manager") and then enumerates exactly what each kind returns: CPU, GPU, memory, fans, network, disk, volume, processes and services. An agent can tell this is live instantaneous telemetry rather than stored/config data. It stops short of naming a sibling like nas_status or nas_system_info, so differentiation is inferred rather than stated.

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?

It explicitly recommends "overview" as "the right first step for 'is the NAS slow'" and scopes sort/top to the processes/services kinds, which is real routing guidance. It also gives a clear negative rule: on older task manager versions everything reports "not available" and should not be retried. No alternative tool is named, so the agent gets context but no explicit either/or with siblings.

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