Skip to main content
Glama

ugreen_cli_help

Read-onlyIdempotent

Shows offline help for unc command groups and subcommands, letting you verify CLI parameters without accessing the NAS or reading login cache.

Instructions

离线查看官方 unc 业务命令组或子命令帮助,确认当前 CLI 的参数。不会访问 NAS,也不读取登录缓存。command 使用空格分隔的命令路径。

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": {
      "command": "<command>"
    },
    "name": "ugreen_cli_help"
  }
}

Input Schema

NameRequiredDescriptionDefault
commandYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it works offline, requires no NAS connectivity, and does not read the login cache — a non-obvious trait that explains why it succeeds when other tools fail. It does not describe the returned help text, but the annotations carry most of the burden.

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 short sentences: purpose first, then the offline/no-credential guarantee, then the parameter format. Nothing is redundant and the most decision-relevant information 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?

For a single-parameter, read-only help lookup with full annotations and an exhaustive enum, the definition covers what an agent needs to call it correctly. Only the shape of the returned help text is unspecified, which is a small gap for a tool with no output schema.

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 0%, so the description has to compensate, and it does state the one non-obvious rule: the command value is a space-separated command path (e.g. group plus subcommand). The enum already lists all valid values, so the remaining gap is minor.

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 names a specific verb and resource: view help for the official 'unc' command group or subcommand, offline. It distinguishes itself from the execution-oriented siblings by stressing 'offline' and 'does not access NAS', though it does not name a sibling tool such as ugreen_execute.

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?

'确认当前 CLI 的参数' states the concrete decision point for using this tool: checking parameter names/usage before invoking a command. It does not explicitly exclude or name alternatives, but the offline scope and the 'no NAS access' note make the boundary clear enough to select it confidently.

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