r2_list_strings

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

With no annotations, the description carries the full burden and uses it well: it discloses a non-mutating listing operation, explains R2-core filtering via bin.str.min for large-file performance, and mandates an existing absolute path while prohibiting fabricating paths or command results. It also exposes the session lifecycle by stating that session_id must be closed when no longer used. Return format and pagination are not covered, but the key behavioral traits are disclosed.

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 purpose sentence and performance note are useful and front-loaded. However, the opening English 'Use when' list and the Chinese trigger-scenario section repeat the same overbroad guidance, and the 'must prioritize' instruction adds noise without supporting correct selection. The description is compact but not every sentence earns 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?

For a simple 3-parameter tool with no output schema and no annotations, the description covers purpose, the absolute-path prerequisite, and session cleanup. But it overstates applicability to disassembly/debugging, does not describe the shape or limits of the returned string list, and does not route the agent to sibling tools for other analysis types. Tightening the use-when and naming alternatives would make it more complete.

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 input schema covers all three parameters—mode, min_length, and session_id—with descriptions, so the baseline is 3. The description's mention of bin.str.min essentially restates the schema's 'R2 核心层过滤' for min_length and adds no new syntax or constraints. No parameter-specific examples or additional semantics are provided beyond the schema.

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 operation—'列出二进制文件中的字符串' (list strings in a binary)—and frames it as the first reverse-engineering step, making the verb and resource specific. It does not explicitly contrast with siblings like r2_list_functions, and the opening 'Use when: disassembly...' list overbroadens the scope, so it stops just short of 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 gives explicit trigger rules: when users ask about binary reverse engineering, disassembly, vulnerability research, radare2 command execution, or debugging, it must be called first. This is misleading because listing strings is not the correct default for those tasks, and no alternatives such as r2_disassemble or r2_list_functions are mentioned. Actively steering the agent to the wrong sibling is worse than providing no guidance.

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