os_list_dir

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

With no annotations provided, the description carries the full behavioral disclosure burden. It usefully reveals that the tool '自动识别并使用 Root 权限' (automatically detects and uses Root permission) and warns against fabricating paths or results. However, it does not describe output format, failure behavior, or side effects, and it includes an irrelevant 'session_id must be closed' rule that does not apply to this tool's single-parameter interface.

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?

The description is overlong for a simple one-parameter directory-listing tool and mixes in repetitive trigger scenarios, emojis, and an unrelated session_id closing rule. The 'Use when' list and the 'trigger scene' section substantially overlap. While some structure exists, several sentences do not earn their place and obscure the core purpose.

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 such a simple tool, the description covers the essential operational details: purpose, absolute-path requirement, Root-permission behavior, and a useful native-library discovery tip. It lacks an output-format description and an explicit exclusion such as 'this only lists directories, use os_read_file to read file contents,' which would prevent misuse given the overbroad trigger section.

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 100%, so the schema already defines the 'path' parameter. The description adds meaningful guidance beyond that: the path must be an absolute path confirmed by the user, paths must not be fabricated, and there is a practical example for locating native libraries under '/data/app/'. This extra context helps the agent supply the parameter correctly.

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 clearly states the tool's action: '列出目录内容' (list directory contents), with an explicit file-directory scope. This distinguishes it from the r2 analysis siblings and os_read_file, which focus on other operations. However, the front-loaded 'Use when: disassembly, radare2, r2...' is overbroad and could imply this tool handles all reverse-engineering tasks rather than just directory listing.

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?

The description provides explicit 'Use when' scenarios and a concrete tip: if unsure about native library location, list '/data/app/' first to locate the package directory. It clearly frames the tool as a supporting step before deeper r2 analysis. It does not mention when to prefer alternatives like os_read_file or termux_command, so it stops short of a full when-not-to-use guide.

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