Lists direct subitems of a data/ directory, returning each item's name, game path, type, size, and extension to help locate files in unpacked game data.
列出 data/ 下某个目录的直接子项（不递归）。
返回每一项的名称、游戏内路径、类型、大小与扩展名，用于定位文件。
| Name | Required | Description | Default |
|---|---|---|---|
| path | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait (non-recursive traversal) and the fields returned, but says nothing about error handling for missing directories, permission/auth needs, or what an empty path resolves to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the scope constraint (non-recursive) front-loaded. The second sentence enumerating returned fields is mildly redundant given an output schema exists, but it is not wasteful enough to penalize further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter listing tool with an output schema present, the description covers purpose, scope, and return shape adequately. The remaining gaps are the default-path behavior and lack of any alternative-tool routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single path parameter, so the description must compensate. It partially does by implying the path is a directory relative to data/, but it never states whether the value is relative or absolute, or how the default empty string is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (列出/list), resource (data/ 下某个目录的直接子项), and explicit scope (不递归), so an agent immediately knows this is a directory-listing tool. It does not explicitly contrast itself with any sibling tool, so it falls short of the top tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the phrase 用于定位文件 (to locate files); there is no statement of when to choose this over read_text, read_xml, or search. No prerequisites or when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.