r2_test

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a diagnostic tool that tests whether the Radare2 library works, and it adds honesty rules such as '禁止捏造不存在的文件路径或命令结果' and 'session_id 不再使用时必须关闭'. However, it does not explain what the tool actually does, what output to expect, whether it opens sessions, or whether it has any side effects, so the disclosure is only partially adequate.

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 cluttered with redundant trigger statements: the English bracketed list and the Chinese '触发场景' section repeat the same overbroad use cases. A simple diagnostic tool should be described in one or two focused sentences. The repeated and misleading trigger text is not concise, and much of it does not earn its place.

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?

Given the rich set of r2_* sibling tools, the description is incomplete because it fails to clarify when to call r2_test instead of the actual analysis tools. It also mentions 'session_id' without explaining how it relates to a tool that has no parameters, and no output schema or return behavior is described. This leaves an agent without enough reliable context to use the tool correctly.

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?

The tool has zero parameters, so the schema already fully documents the parameter surface; the baseline is 4. The description does reference an absolute file path and session management, but these are not declared as parameters, which creates mild ambiguity. Still, because there are no parameters to explain, the description does not need to compensate and receives the 0-parameter baseline.

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 contains a clear diagnostic purpose: '测试 Radare2 库是否正常工作' (test whether the Radare2 library works normally). This specific verb+resource distinguishes it from sibling tools like r2_disassemble and r2_decompile_function. However, the first line broadly claims 'Use when: disassembly, radare2, r2, debugging...' which muddies the purpose slightly and prevents a 5.

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 says this diagnostic tool 'must be prioritized' whenever users ask about binary reverse engineering, disassembly, vulnerability research, or radare2 command execution—but those tasks belong to sibling tools such as r2_disassemble, r2_decompile_function, and r2_run_command. This is misleading guidance that would cause an agent to invoke a test tool for real analysis work, and no alternatives or exclusions are mentioned.

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