Skip to main content
Glama
haoan33

OmniQQ-MCP

by haoan33

get_group_root_files

List all files and folders in a QQ group's root file directory, enabling AI agents to browse and manage shared group storage.

Instructions

获取 QQ 群文件根目录下的所有文件与文件夹列表 (NapCat OneBot 11: get_group_root_files)。 :param group_id: 群号

Input Schema

NameRequiredDescriptionDefault
group_idYes群号

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. '获取' implies a read-only listing, but the description says nothing about return format, pagination, item counts, or permission requirements, which matters for a folder/file listing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the trailing ':param group_id: 群号' is pure duplication of the schema field and the parenthetical '(NapCat OneBot 11: ...)' is an implementation reference rather than agent-useful context. Adequately sized but with redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with no output schema and no annotations, the description covers what it does but omits the shape of the result (file/folder entries) and any behavioral caveats. It is minimally adequate but not complete given the absence of structured fields.

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 100% for the single group_id parameter, so the schema fully documents it. The description merely repeats ':param group_id: 群号', adding no format or semantic meaning beyond the schema. Baseline 3 applies.

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?

States a specific verb (获取/get) and resource (QQ 群文件根目录下的所有文件与文件夹列表), with the 'root directory' scope distinguishing it implicitly from the sibling get_group_files_by_folder. It does not explicitly name the sibling, but the resource and scope are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The word '根目录' (root directory) weakly implies it contrasts with get_group_files_by_folder, but this is inference, not stated guidance.

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