ugreen-nas-mcp

Overview Schema Source Related Servers Discussions Admin

Read container or project logs

nas_docker_logs

Read-only

Fetch recent Docker logs from a NAS by container ID or Compose project name, returning the latest 200 entries for troubleshooting. Use it to inspect current container or combined project output.

Instructions

Fetch recent log output (data.logs, one multi-line string). target "container" takes the full container_id from nas_docker_containers and returns the latest 200 entries. target "project" takes a project_name from nas_docker_projects and returns the combined log of all its containers, 200 lines in total, possibly with ANSI colour codes. There is no way to get older lines, follow the log or filter by time; for that the user needs the Docker app on the 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": {
      "target": "<target>",
      "id": "<id>"
    },
    "name": "nas_docker_logs"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Full container_id, or the Compose project_name.
`target`	Yes	Whose log to read.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

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 adds substantial beyond-schema detail: output lands in data.logs as a single multi-line string, container mode returns the latest 200 entries, project mode returns 200 lines combined across containers, and ANSI colour codes may be present. It also discloses hard limits (no pagination or time filtering), which is exactly the behavioral context an agent needs before calling.

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 tight sentences, front-loaded with the return shape, then per-target semantics, then limits. Every clause carries information; nothing is redundant filler despite the density.

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?

No output schema exists, and the description compensates by naming the return field, its type, and the entry counts per mode. For a two-parameter read tool with limitations explicitly enumerated, nothing an agent needs in order to call it 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 would be 3, but the description adds real meaning by tying each target value to a specific source system for the id and clarifying that project mode aggregates across containers. The id format nuance (full container_id, not a short id or name) is reinforced rather than merely repeated.

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?

States a specific verb and resource ("Fetch recent log output") and immediately disambiguates the two modes via the "container" and "project" targets. It names the sibling tools that supply the required identifiers (nas_docker_containers, nas_docker_projects), so an agent can tell this apart from container/project listing tools without opening a schema.

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 maps each target value to the correct id source, and states the negative space clearly: no older lines, no follow/tail, no time filtering, and where to go instead (the Docker app on the NAS). That is a genuine when-to-use and when-not-to-use statement rather than an implied one.

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