r2_list_functions

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

With no annotations, the description provides some behavioral context: it uses the 'afl' command, filter prevents excessive output, and it includes rules about confirming file paths, not fabricating results, and closing the session. However, it does not explicitly state whether the operation is read-only, whether an open session is required, or what side effects (if any) occur.

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 verbose and cluttered, mixing English and Chinese with emojis and bracketed sections (触发场景, 使用规则). The core purpose is buried near the beginning but followed by repetitive trigger scenarios and usage rules that are not tightly scoped. It lacks effective front-loading and concise structure.

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?

The description does not explain the return format or pagination behavior, and it does not mention that the tool likely requires an existing session (implied by session_id but not stated). While it includes operational rules, these are more about usage discipline than providing the agent with all necessary context to call the tool correctly. No output schema exists, so the description should describe the return value, which it does not.

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 all parameters (session_id, limit, filter) are already documented with descriptions. The tool description adds only a filter example ('sym.Java') and a note to limit output, which provides marginal extra meaning 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 explicitly states '列出二进制文件中的已识别函数' (list recognized functions in binary file) and mentions the underlying 'afl' command and optional filter. This gives a clear, specific verb+resource that distinguishes it from disassembly, decompilation, and string-listing tools.

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 '触发场景' section claims the tool must be prioritized for any binary-analysis, reverse-engineering, or debugging question, which is overly broad and fails to differentiate it from many siblings like r2_disassemble or r2_decompile_function. No specific alternatives or conditions for choosing this tool over others are provided.

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