Skip to main content
Glama
Sign In
ugreen-nas-mcp

ugreen-nas-mcp

by Mrgaols
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read part of a file

nas_file_read
Read-only

Read bytes from any file on your UGREEN NAS directly in memory, without downloading it. Returns UTF-8 text or base64 content in chunks so you can inspect or stream files by offset.

Instructions

Read bytes from a file on the NAS without saving it locally. Returns { path, offset, bytes, encoding, content }: encoding is "utf8" when the bytes are valid UTF-8 text, otherwise "base64". By default the first 64 KiB are read and at most 1 MiB per call; for a longer file call again with offset increased by the bytes already read. A result with fewer bytes than requested means the end of the file was reached. To copy a whole file to this computer use nas_file_download.

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": "nas_file_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesFile to read. Absolute NAS path, for example /volume1/docs/report.pdf.
lengthNoNumber of bytes to read (max 1048576).
offsetNoByte offset to start reading at.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still adds substantive behavior beyond them: the default 64 KiB read, the 1 MiB per-call cap, the returned field set, and the utf8-vs-base64 encoding rule. It also documents how partial results relate to end-of-file, which no annotation conveys.

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?

Four sentences, each carrying distinct information: purpose, return shape, chunking mechanics, EOF detection, and the sibling escape hatch. The most decision-relevant facts (what it does, what it returns) are front-loaded with no filler.

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?

There is no output schema, but the description enumerates the return object shape and the encoding semantics, so an agent knows what to expect. For a three-parameter read tool with full annotation coverage, nothing needed to call it or interpret results 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 baseline is 3, but the description adds meaning the schema cannot express: the relationship between length and offset across successive calls and the maximum-per-call constraint in operational terms. It does not restate path formatting, which the schema already handles well.

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 and resource ("Read bytes from a file on the NAS") plus a scoping constraint ("without saving it locally") that distinguishes it from a download. It also names the sibling nas_file_download for the whole-file case, so the agent can disambiguate without inspecting 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 gives an explicit chunking procedure (call again with offset increased by bytes already read), a termination signal (fewer bytes than requested means EOF), and an explicit alternative for whole-file copies (nas_file_download). When-to-use, how-to-continue, and when-to-use-something-else are all covered.

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