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

There are no annotations, so the description carries the full burden. It discloses a key behavioral trait: notes persist and are automatically loaded when the file is next opened to prevent information loss. It also includes guardrails against fabricating file paths and about closing session_id, though the session_id rule is not clearly connected to this tool's parameters.

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 two-parameter tool and bundles an umbrella reverse-engineering tag, trigger scenarios, and usage rules with emoji headings. Some content, especially the session_id rule, is unrelated to this tool's exposed parameters and should have been omitted; the key persistence behavior is buried in the middle.

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 gives enough for the core call: two required params, the persistent side effect, and examples. But it introduces a problematic requirement to confirm an absolute file path and close session_id even though neither appears in the input schema, leaving ambiguity about how the target file/session is supplied and what the tool returns.

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 description coverage is 100%, so the baseline is 3. The description adds an example of a note ('AES Key 生成函数...') and mentions relevant addresses, but these largely repeat or illustrate what the schema already states rather than adding new parameter semantics.

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 action: 向持久化知识库添加笔记 (add a note to the persistent knowledge base), and gives concrete examples such as recording keys and algorithm principles. No sibling tool covers persistent note storage, so it is easy to distinguish from the r2 analysis commands.

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?

It provides explicit 'Use when' context for reverse-engineering, disassembly, radare2, and vulnerability research, and adds a trigger scenario saying it must be prioritized for those topics. However, it does not state when not to use it or name an alternative tool, and the broad 'must prioritize' phrasing could over-trigger invocation.

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

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

No annotations exist, so the description carries the full burden. It explicitly warns that the operation directly modifies memory/file and advises simulated execution first, plus instructs to confirm absolute paths and close session. It does not mention reversibility or error behavior, so not a perfect 5.

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?

Structured into intro, warning, and rules, but repeats the use-when list in the trigger scene and includes decorative/boilerplate text. It is not badly bloated, yet every sentence doesn't 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?

For a mutating r2 tool with no annotations and no output schema, the description gives enough to call safely: format of bytes, warning, path confirmation, session cleanup, and a simulation fallback. Missing return-value expectations and clear persistence semantics are minor gaps.

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?

All 3 params are documented in the schema (100% coverage), so baseline is 3. The description adds example values and clarifies hex_bytes needs no spaces, but contributes nothing new for session_id and only loosely maps to 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?

States an explicit action—apply a binary patch at a given address—with concrete purposes (bypass checks, alter return values) and a concrete example. This clearly distinguishes it from sibling read/analysis tools like r2_disassemble.

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?

Provides some context (patch for bypass checks, use simulation first if unsure), but the trigger scene says to 'must prioritize this tool' for all disassembly/debugging questions, which is overbroad and conflicts with siblings such as r2_disassemble. It lacks explicit when-not-to-use guidance, so selection among siblings is not reliably grounded.

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

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

With no annotations, the description carries the burden and does a good job: it discloses that the tool performs simulated batch execution, locates function references, patches stack/init state, and cannot handle external calls like malloc/JNI. It also warns about session cleanup, though it does not describe the return format or side effects on sessions in detail.

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 bullet list and parameter examples are useful, but the opening tags, repeated '批量解密', and a trigger paragraph that largely repeats the opening make it less tight. It is not egregiously long, but it does not satisfy the zero-waste standard.

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 is fairly complete for a complex 7-parameter, no-output-schema tool: it explains architecture adaptation, stack/memory issues, limitations, and path prerequisites. Gaps remain around what the batch result actually looks like and how session_id is created/closed beyond 'when no longer used'.

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 already covers all parameters (100% coverage), establishing baseline 3. The description adds value by explaining how instr_size/result_reg adapt to architectures, custom_init solves stack passing, and map_size addresses memory layout—linking parameters to concrete failure modes beyond the schema text.

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 core purpose is clear: batch-decrypt strings by emulative/backtracking execution, aimed at OLLVM and custom algorithms. It does not name a sibling such as simulate_execution or r2_list_strings to distinguish itself, and the opening 'Use when: disassembly, radare2...' broadens the purpose beyond what this specialized tool does, which lowers it from 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 trigger statement says it 'must' be prioritized for any binary/RE/radare2/debugging question, which is not reliable guidance and would over-select this tool relative to r2_disassemble and r2_run_command. The 'pure algorithm only' and 'cannot simulate malloc/JNI' notes are useful exclusions, but no alternative tool is mentioned and the when-to-use guidance is misleadingly broad.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool searches for and frames it as the Android reverse-engineering entry point, and it adds session-lifecycle and anti-fabrication rules. However, it does not describe output format, failure behavior, or potential side effects.

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 repeated tags, emojis, and dupliced trigger scenarios. The core function is buried among meta-instructions; a tighter two-sentence definition would serve agents better.

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 single-parameter tool with no output schema, it covers what the tool does, when to call it, prerequisites, and session hygiene. It does not specify the return format, but the list output is implied and session creation is covered by sibling tools like r2_open_file and r2_close_session.

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 baseline is 3, but the description adds lifecycle/precondition meaning: session_id must be tied to a real absolute path, must not be fabricated, and must be closed when no longer used. It does not explain how to obtain the session_id, but it does add value 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 identifies the tool as JNI method discovery for Android binaries, specifically listing static exported 'Java_' symbols and 'JNI_OnLoad' functions. This distinguishes it from generic siblings like r2_list_functions or r2_disassemble by naming the exact artifact and entry-point purpose.

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?

Explicit trigger scenarios are given (binary analysis, disassembly, debugging, vulnerability research), plus a mandatory-precedence rule requiring this tool for such tasks. It also states prerequisites like confirming an absolute file path and not fabricating results, though it does not explicitly name sibling alternatives or when not to use it.

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

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.

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

With no annotations, the description carries the transparency burden and largely succeeds: it discloses auto-root escalation, automatic truncation over 50KB, cat-based read behavior, and the crash risk of reading binary files. It could add more about output format or root side effects, but the key behaviors are clearly stated.

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 and repetitive, mixing English and Chinese with duplicate trigger/usage blocks. The misleading first line and repeated warnings could have been condensed into a single clear section; structure is front-loaded but bloated.

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 one-parameter text-reading tool, the description covers the necessary safety and usage context: path validation, no binary files, truncation, and root escalation. However, the contradictory reverse-engineering trigger and the orphaned instruction about closing a session_id (which is not a parameter of this tool) leave the overall context incomplete and potentially confusing.

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 schema already documents the single 'path' parameter with 100% coverage, giving the baseline of 3. The description adds practical semantics beyond the schema by requiring an absolute path and explicitly prohibiting fabricated or non-existent paths.

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 core operation is clear: '读取文件的文本内容 (基于 cat)' identifies a text-file reader for a path. However, the opening line calls it a 'Binary/reverse-engineering tool' for disassembly/r2/debugging, which directly conflicts with its actual behavior and the explicit warning not to read binaries, severely muddying what the tool is for.

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?

It gives explicit exclusions and alternatives: binary files must go to r2_open_file, and callers must provide a real absolute path. But the '触发场景' says this tool must be prioritized for binary reverse engineering, which contradicts the binary warning and makes the when-to-use guidance unreliable.

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

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

No annotations are present, so the description carries the burden. It discloses the effect of each operation including the destructive remove/all-hints-clearing, and adds session/path rules. It does not state whether modifications persist to disk or only the session, what is returned, or whether an open session is required.

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 action table is useful and earns most of its length, but there is redundancy: the top 'Use when' list overlaps with the later trigger scene, and the broad RE label is not necessary for a hints-management tool. Structured with headings, but not tight.

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 7-action, no-annotation, no-output-schema tool, it covers actions, value semantics, session handling, and anti-hallucination rules. The main gaps are the lack of any description of the return/output format and the persistence model of hint modifications, which leaves some uncertainty for an agent.

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%, and the description adds substantial extra meaning: each action is mapped to concrete value examples, set_base radix options are specified, address defaults to cursor, and session lifecycle is explained. This removes most ambiguity in action-specific parameter usage.

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?

States a specific verb and resource: managing R2 analysis hints, with a clear list of sub-operations. It is distinguishable from sibling analysis tools because it targets hints/correction and display optimization, though the opening 'binary/reverse-engineering tool' label is broad and overlaps with many siblings.

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?

Provides concrete when-to-use conditions: when disassembly looks wrong, immediate values are confusing, or control flow breaks, and lists RE trigger scenarios. It lacks explicit when-not-to-use or named alternatives, and the rule to 'must call first' for all RE questions is overbroad since this tool only manages hints.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool runs aaa analysis, automatically releases resources, supports session_id reuse or lookup by file path, and instructs the agent to close unused sessions. The session lifecycle is slightly ambiguous but not contradictory.

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 trigger information is repeated in the Use-when list and the trigger scene, and the text mixes emoji, bracket labels, Chinese, and English unnecessarily. It could be condensed to a few focused sentences without losing content.

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 tool is complex and has no output schema or annotations, yet the description omits what the analysis result looks like and how to choose between providing session_id and letting it resolve by file_path. It does cover path safety, session reuse, and cleanup, making it minimally adequate.

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 baseline is 3, but the description adds useful semantics: file_path must be an absolute path, invented paths/results are forbidden, and session_id can be used to reuse an existing session or locate it by file path.

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 identifies a concrete action: running a one-shot radare2 deep analysis (aaa) on a binary file and releasing resources. It also lists applicable domains, though the broad trigger list overlaps with sibling tools such as r2_disassemble and r2_decompile_function.

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 trigger scenes and a mandatory-priority rule for binary analysis requests. However, it gives no exclusions or alternatives, and its trigger list is broad enough that an agent cannot tell when to choose r2_disassemble or r2_decompile_function instead.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add useful constraints: 'full' analysis is extremely slow, absolute file paths must be confirmed, fabricated paths/results are forbidden, and session_id must be closed when unused. But it does not disclose what the tool returns, whether it mutates the r2 session state, or what side effects running a strategy has, leaving important operational behavior under-specified.

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 strategy list is well-structured and front-loaded with the use case. However, the English '[Use when...]' block and the later Chinese trigger-scenario block largely duplicate each other, and the emoji/bracket wrapper adds noise. The content earns its place, but the redundancy and mixed formatting make it less tight than it could be.

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 is strong on strategy selection, performance cautions, and usage rules. But with no output schema and no annotations, it omits the return/output contract entirely: an agent is not told what the tool produces after running a strategy, how results are presented, or how the target file is associated with session_id. This is a significant gap for a tool with this much operational nuance.

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%, but the description adds substantial meaning beyond the schema. Each strategy enum value is mapped to its radare2 command and purpose, the address parameter's optional/default behavior is clarified, and session_id lifecycle guidance is provided. This goes well beyond the schema's bare parameter labels.

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 states a specific action: execute a selected Radare2 recursive analysis strategy (aa/aab/aac/aar/aad/aaa), which is more specific than the tool name alone. It clearly positions the tool in the binary/reverse-engineering domain, but it does not explicitly distinguish itself from siblings like r2_analyze_file or r2_disassemble, so it falls 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?

It provides an explicit 'Use when' list and a trigger-scenario rule saying this tool must be prioritized for reverse-engineering, disassembly, and debugging requests. It also advises choosing the lightest strategy and reserving 'full' for small files. However, it does not state when to prefer siblings such as r2_disassemble or r2_run_command, so exclusion guidance is missing.

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

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

No annotations are provided, so the description carries the burden. It adds a useful behavioral rule against fabricating paths or command results, and reminds that sessions must be closed when no longer needed. However, it does not disclose important close-session behavior such as whether the session is permanently invalidated, whether unsaved state is lost, or what happens after closing.

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 padded with generic boilerplate ('Binary/reverse-engineering tool', 'r2ai逆向工具', broad trigger scenarios) and repetitive brackets. Only the core close-session sentence and the 'close when unused' rule are directly relevant. Several sentences actively mislead tool selection and should be removed.

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 tool, the description does not explain where session_id comes from (e.g., from r2_open_file or session creation). It also includes an irrelevant rule about confirming a target absolute file path, even though this tool takes no path parameter. The close-when-unused hint is helpful, but the tool's invocation context is incomplete.

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 already describes the only parameter, session_id, as '会话 ID', so schema coverage is high. The description does not add extra meaning beyond '必须在不再使用时关闭', which is a lifecycle note rather than parameter format, origin, or usage detail. Baseline 3 is appropriate.

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 primary action: '关闭指定的 Radare2 会话' (close the specified Radare2 session), which is a specific verb and resource. However, the surrounding '触发场景' lines claim this tool must be prioritized for all binary reverse-engineering questions, which muddles tool selection and blurs the distinction from sibling tools like r2_open_file, r2_run_command, and r2_disassemble.

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?

There is some valid usage guidance: 'session_id 不再使用时必须关闭' (must close when the session_id is no longer used). But the description also instructs the agent to call this tool first for any disassembly, debugging, or vulnerability analysis question, which is misleading for a close-session operation. No alternatives or exclusions are named.

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

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

No annotations are provided, so the description carries the disclosure burden. It explains that the tool manages Radare2 eval variables, lists useful config keys, and includes operational rules such as not fabricating file paths or command results and closing the session_id when done. It does not disclose side effects of 'set' (e.g., persistence or impact on the session/analysis state) or what get/list return, leaving some behavioral gaps.

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 sectioned and the config-key reference is practical and useful. However, it is verbose and somewhat repetitive: the broad opening 'Use when' list overlaps with the later trigger scenario, and the 'must prioritize' sentence adds noise rather than selection value. It could be tightened without losing the valuable config guidance.

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 provides substantial config-key context and usage rules, which is helpful for correct invocation. But with no output schema, it does not explain what get/list return, and it does not mention how session_id should be obtained (e.g., from r2_open_file) or whether a target file must already be loaded. These are meaningful gaps for a tool that depends on an active r2 session.

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 already describes all parameters with 100% coverage, so the baseline is 3. The description adds real value by enumerating concrete config keys ('anal.strings', 'anal.bb.maxsize', 'anal.in' modes) and value examples, which helps an agent choose meaningful key/value pairs beyond the generic schema descriptions. Value format is only illustrated by example, not fully formalized.

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 identifies a specific resource (Radare2 analysis/display eval variables) and action (manage via get/set/list), and provides concrete triggers like poor analysis results or function truncation. This distinguishes it from sibling r2 tools. However, the opening 'Binary/reverse-engineering tool. Use when: disassembly, radare2, debugging...' is overly broad for a config manager and slightly dilutes the purpose.

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 concrete use cases: when analysis results are unsatisfactory, when functions are truncated, and for deep analysis/config tuning. It does not explicitly name sibling alternatives or state when not to use this tool. The instruction to 'must prioritize this tool' for any disassembly/reverse-engineering question overstates its role, since siblings like r2_disassemble or r2_analyze_target are more appropriate for those tasks.

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

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

With no annotations, the description carries the full burden. It does disclose the use of the 'pdc' command, the output type (C-like pseudocode), and important rules like not fabricating file paths and closing the session when done. However, it does not describe side effects, error conditions, or session state requirements, so transparency is partial.

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 repetitive and verbose, repeating the same trigger scenarios in multiple formats (English bracket, Chinese icon section, and again in 使用规则). It includes promotional and emoji-heavy phrasing that does not add information. The core behavior and rules could be stated in one or two clear sentences.

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 covers the core operation and output, and mentions session closure. But it omits essential preconditions: that session_id must come from an already-opened r2 session, that the target file must already be loaded, and how the result is returned. It also imposes an 'absolute path' prerequisite that does not match any input parameter, which could confuse an agent. Overall, it is adequate but has clear gaps for reliable invocation.

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 100% of parameters, so the baseline is 3. The description adds the useful address format example ('0x401000 或 main'), but says nothing beyond the schema about session_id or its relationship to an open r2 session. This matches the baseline without meaningful enrichment.

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 a specific verb and resource: '反编译指定地址的函数为伪代码' (decompile a function at a specified address to pseudocode). It also names the underlying mechanism ('pdc' command) and output format, which distinguishes it from sibling tools like r2_disassemble and r2_run_command.

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 scenarios ('当用户询问二进制逆向分析、反汇编、漏洞挖掘...') and says this tool must be called preferentially. However, it is overbroad and even says 'radare2命令执行' should prioritize this tool, which conflicts with the existence of sibling r2_run_command. No when-not-to-use or alternative routing guidance is provided, so an agent could pick the wrong tool.

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

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

该工具没有 annotations，描述承担了行为披露的责任。它说明了内部使用 'pd' 命令、要求确认目标文件绝对路径、禁止捏造路径或命令结果，并提醒 session_id 不再使用时必须关闭，这些是超出 schema 的有用行为信息。但未说明是否需要先打开文件、是否依赖已激活的 r2 会话，副作用披露仍不完整。

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?

核心功能、触发场景、使用规则分节明确，且功能信息前置。但英文 “Use when” 列表与中文“触发场景”内容高度重复，存在冗余，整体不够精炼。

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?

对于 3 参数、无输出 schema 的工具，描述已覆盖功能、使用时机、输入前置条件和资源清理规则，足够支持基本调用。未说明返回格式或如何获取 session，但“显示汇编指令”的语义已隐含输出形态，影响不大。

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 覆盖率为 100%，session_id、address、lines 三个参数都已有清晰描述，description 未逐参数补充额外语义。它只是复述“指定地址”和使用 pd 命令，未超出 schema 已提供的信息，因此保持在基线 3 分。

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?

描述明确说明“反汇编指定地址的代码”并指出使用 'pd' 命令显示汇编指令，动作和对象清晰。但没有显式与 r2_run_command、r2_decompile_function 等兄弟工具区分，触发场景中还混入“radare2命令执行”这类宽泛表述，略微削弱辨识度。

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?

有专门的触发场景说明：“当用户询问二进制逆向分析、反汇编、漏洞挖掘、radare2命令执行、调试相关问题时，必须优先调用此工具”，给出了明确的 when-to-use。但没有提供 when-not-to-use 或与替代工具的对比，且“radare2命令执行”范围过宽，可能误导代理优先选择此工具而非 r2_run_command。

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses session lifecycle behavior (must close session_id), warns against fabricating file paths or results, and implies read-only information retrieval. However, it does not clarify whether the tool opens a session, requires an existing session, or has other side effects.

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 overly verbose and repetitive. The English 'Use when' list and the Chinese 【触发场景】 section restate the same triggers, and the opening bracket with emoji adds noise. Core information is buried in redundant marketing-style labels rather than being concise and front-loaded.

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?

Despite covering triggers and rules, the description misses a critical operational detail: how to obtain or provide the target file path. There is no path parameter in the schema, yet the description requires the user to provide an absolute path, suggesting a dependency on a prior r2_open_file call that is never explained. The 'detailed' mode is also left vague, and with no output schema, the agent has insufficient context to reliably invoke this 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a small amount of semantic value by mentioning that session_id should be closed when no longer in use. It does not clarify how the target file path relates to the session_id or what 'detailed' actually changes, leaving parameter meaning mostly reliant on the schema's minimal descriptions.

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 purpose: '获取二进制文件的详细信息' (get detailed information of a binary file), including architecture, platform, and file type. This is a specific verb+resource. However, it does not explicitly distinguish itself from sibling tools like r2_analyze_file, and the trigger scenarios overlap with several other r2 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 description provides explicit trigger scenarios: when users ask about binary reverse engineering, disassembly, vulnerability research, or radare2 command execution, this tool must be called first. It also states a key prerequisite: confirm the absolute path of the target file, and a lifecycle rule: close the session when no longer needed. It lacks explicit 'when not to use' or references to alternatives.

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

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

No annotations are provided, so the description carries the full disclosure burden. It adds usage ruiles like confirming the absolute path, not fabricating paths/results, and closing the session, but it does not explain the tool's actual behavioral profile: whether it is read-only, whether it depends on an already-open r2 session, what it returns, or what side effects (if any) the session management has.

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 overloaded with emojis, repeated trigger scenarios, and a broad 'must prefer this tool' block before reaching the actual purpose. It is not concise; the useful information could be captured in one sentence.

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?

With no output schema and no annotations, the description should explain prerequisites and expected behavior. It mentions closing the session but not how to obtain a session_id, that the target file must already be opened via r2_open_file, whether the session must be valid, or what kind of xref list is returned.

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 description coverage is 100%, so the parameters are already documented with types, defaults, and meanings. The description adds marginal context by saying 'address/function' maps to the address parameter, but does not add any semantics beyond what the schema already provides.

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 core sentence '获取指定地址/函数的交叉引用' clearly states the specific action and resource, and '逻辑追踪必备' distinguishes it as a logic-tracing/reference tool. However, the front matter 'Use when: disassembly, radare2, debugging...' overreaches and could make the agent think this tool handles broad reverse-engineering tasks beyond xrefs.

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 explicitly says '当用户询问二进制逆向分析、反汇编、漏洞挖掘、radare2命令执行、调试相关问题时，必须优先调用此工具', which is misleading: this tool only fetches xrefs, and sibling tools exist for disassembly, decompilation, and command execution. It names no when-not-to-use conditions and no alternatives, so it actively misroutes rather than guides.

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

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.

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.

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

没有注释信息，所以描述承担了行为披露责任。描述明确列出了 add_code/add_call/add_data/add_string/remove_all 等写操作及其含义，能让代理知道这些会修改分析结果；也提到了“修复错误的分析”。但它没有说明修改是否会持久化、是否需要已有打开的文件、session_id 如何获得，以及操作可能的副作用。

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?

描述结构清晰，操作列表分段明确，但篇幅偏长，且夹杂了图标、大段‘触发场景’和‘使用规则’。其中“必须确认目标文件绝对路径”与当前参数列表没有直接对应关系，显得冗余甚至干扰。整体信息密度尚可，但不够精炼。

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?

工具涉及 7 种操作且无输出 schema，描述对每种操作都给出了说明，基本能指导代理选择 action 和填写参数。但缺少关键前置条件说明，比如 session 如何获得、目标文件是否已打开；同时“必须确认绝对路径”这一规则与本工具参数不一致，造成上下文不完整。

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 覆盖率为 100%，因此已含参数基础描述；但说明进一步把 action 枚举值映射到 radare2 命令（axt/axf/axc/axC/axd/axs/ax-），并解释了 list_to 与 list_from 的区别，以及 source_address 的默认行为。这明显补充了 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?

描述以“管理代码和数据的交叉引用”开头，明确给出了具体动词和资源，并列出 list/add/remove 等操作，说明这是一对引用进行查询和修改的工具。虽然与同族的 r2_get_xrefs 在查询类操作上可能存在重叠，但整体上仍足以让代理辨明其主要职责。

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?

描述包含“触发场景”，但范围过于宽泛，声称逆向分析、反汇编、漏洞挖掘、调试等场景“必须优先调用此工具”，这会把代理错误地引导到一个只管理 Xrefs 的工具上，而非真正的反汇编或调试工具。没有说明何时不应使用本工具，也没有与 r2_get_xrefs、r2_run_command 等替代工具进行区分。

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

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

With no annotations, the description carries the full burden. It discloses default basic analysis, the timeout risk for >10MB files, session management (must close), and a prohibition on fabricating results. It does not mention file-modification side effects or error behavior, but for an open-and-analyze tool this is largely adequate. A 4 is appropriate.

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 structured with sections but is verbose, including emojis, bilingual text, and some redundancy (e.g., repeating the 10MB hint found in the schema). The purpose is front-loaded, but extra formatting and duplication reduce clarity. It could be tightened without losing information.

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 tool's complexity (3 params, no output schema), the description covers the essentials: when to use, what it does, parameter caveats, and session management. It doesn't specify return format or error handling, but these aren't required when no output schema exists. It is fairly complete for an agent to call it 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?

Schema coverage is 100%, so parameters are already documented. The description repeats the 10MB hint for auto_analyze (already in schema) and adds a rule about confirming absolute paths (also in schema). It adds minimal extra meaning, like the session-close note, but overall doesn't go beyond the schema enough to merit above baseline 3.

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 states a specific verb and resource ('打开二进制文件' - open binary file) and enumerates concrete use cases (disassembly, radare2, debugging, vulnerability research, ELF/PE/SO/DEX analysis). It also differentiates from siblings by explicitly directing deep analysis to r2_analyze_file or r2_run_command, making the purpose unmistakable.

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?

It provides an explicit 'Use when' list, a trigger scenario, and clear rules (confirm absolute path, don't fabricate results, close sessions). It also names alternatives for deeper analysis and warns about auto_analyze for large files. This is comprehensive guidance on when and when not to use the tool.

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

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

With no annotations, the description carries the transparency burden and does contribute useful behavioral context: it warns against fabricating paths/results, requires the session to be closed when unused, and notes that arbitrary r2 commands are supported. Still, it does not disclose that arbitrary commands may have write/side effects, how errors are surfaced, or what the output format is.

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 core statement is concise and front-loaded, but the description contains redundancy and metadata noise (bracketed tags, emoji, repeated trigger scenarios). The information is adequate but could be tightened into a cleaner directive without losing meaning.

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 an arbitrary-command execution tool with no output schema and no annotations, the description covers several operational essentials: when to use it, path confirmation, and session cleanup. It is incomplete, though, because it does not explain how a session_id is obtained, what output the caller should expect, or the potential consequences of running arbitrary r2 commands.

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 description coverage is 100%, so the baseline is 3. The description adds no real semantic detail beyond the schema: it does not explain command syntax expectations, whether r2 commands are passed verbatim, or how the session_id relates to an opened file.

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 executes arbitrary Radare2 commands in a specified session and declares support for all r2 commands. It identifies the resource (session) and action (run command) unambiguously, though it does not explicitly differentiate itself from specialized siblings like r2_disassemble or r2_decompile_function.

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 scenarios and a rule to prioritize this tool for reverse-engineering/radare2 questions, plus preconditions such as confirming an absolute path. However, it provides no exclusions or guidance on when to choose specialized sibling tools instead, and the blanket 'must call for disassembly' is potentially misleading given dedicated r2_disassemble/r2_decompile_function tools exist.

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

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.

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

With no annotations, the description must carry the behavioral burden. It mentions that it reads system logs for crash stacks and patch debugging, and that root may be needed for other apps' crashes (via use_root). However, it includes behavioral rules about confirming file paths and closing a session_id that are not applicable to logcat, and it mischaracterizes the tool as a binary reverse-engineering utility. This inconsistency undermines transparency, so the score is low despite some relevant details.

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 redundant. The opening preamble about binary/reverse-engineering and the trigger scenario repeat similar information. The usage rules about file paths and session_id are irrelevant and add noise. It is not front-loaded; the key purpose appears only after generic tool classification. The excessive, partially unrelated text hurts conciseness.

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 lacks essential context for a logcat tool: it does not describe the output format, how to handle multiple logs, or error conditions. It introduces irrelevant requirements (file path, session_id) that could mislead an agent. While the schema covers parameters, the overall guidance is incomplete and partly contradictory, leaving gaps for a successful invocation.

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%, and the schema descriptions are clear: lines (suggested range and default), filter (keyword, optional), use_root (required for other app crashes). The description text adds little beyond these schema definitions—it mentions crash stack analysis but does not elaborate on parameter usage. Since the schema already documents all parameters well, the baseline of 3 is appropriate.

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 verb 'read' and resource 'Android system log' (读取Android系统日志), and mentions analyzing crash stacks and debugging patch results. However, it opens with 'Binary/reverse-engineering tool' and lists disassembly, radare2, and vulnerability research as use cases, which are unrelated to reading logcat and muddle the actual purpose. This conflicting context prevents a higher score.

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 a trigger scenario instructing to 'must prioritize this tool' for binary reverse analysis, disassembly, and radare2 command execution, which is misleading because logcat is not for those tasks. It does not mention any alternatives or when not to use logcat. The usage rules about confirming a target file's absolute path and closing a session_id are unrelated to logcat, providing no useful guidance for selecting this tool over siblings.

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

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

With no annotations provided, the description carries the full burden and discloses important side effects: renaming persists automatically to a local knowledge base and survives session restarts. It also warns against fabricating paths or command results and instructs closing session_id when no longer needed, which is useful behavioral context.

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 organized with bracketed labels and rule sections, which helps structure. However, it repeats trigger scenarios and overuses phrases like '必须优先调用此工具' (must prioritize calling this tool), adding redundancy that could confuse an agent about when this tool is actually the right choice.

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 mutating tool with no annotations and no output schema, the description covers the key operational details: when to invoke, what preconditions exist, persistence behavior, and session cleanup. Minor gaps remain around what the tool returns or whether renaming can be undone, but the description is sufficient for correct invocation.

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 description coverage is 100%, so the baseline is 3. The description adds some meaning around session_id lifecycle and why the name parameter is used, but it does not clarify the address parameter and introduces a 'target file absolute path' rule that does not map cleanly to the actual schema parameters.

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 renames functions ('智能重命名函数') and specifies the exact condition for use: once the agent has identified a function's purpose. It also distinguishes itself from sibling tools like r2_disassemble or r2_list_functions by adding the persistence-to-knowledge-base behavior.

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 trigger scenarios, such as when the user asks about binary analysis, disassembly, or radare2, and gives a clear precondition that the user must supply the target file's absolute path. It does not name sibling alternatives or state when NOT to use this tool, so it falls short of a 5.

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

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

With no annotations, the description must carry the full burden. It explains that the tool scans and auto-discovers crypto constants, but it does not disclose whether it is read-only, whether it requires an already-open r2 session, what state it changes, or how results are delivered. The closing-session rule hints at lifecycle side effects but does not explain them.

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 core description is reasonably compact and front-loaded with the scanner purpose. However, it is padded with bracket tags, repeated trigger scenarios, and mixed-language formatting that make it less crisp than it could be, and the broad "must call this" rule adds noise.

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 tool with only session_id as a parameter and no output schema, the description leaves a key gap: it insists the user's absolute file path be confirmed, but no path parameter exists, implying a session must already be open without explaining that prerequisite. It also fails to say what happens after the scan and how results are surfaced.

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 schema already documents session_id with 100% coverage, so the baseline is 3. The description adds some lifecycle context ("session_id 不再使用时必须关闭") but does not meaningfully elaborate what session_id refers to or how it relates to the required file path, which is not a parameter in 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 states a specific verb and target: scan a binary file for cryptographic constants and magic numbers, with concrete examples (AES S-Box, RSA Keys, MD5/SHA constants). This distinguishes it from sibling disassembly/analysis tools, though it does not name those siblings explicitly and wraps the purpose in broad reverse-engineering trigger language.

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?

It gives a clear when-to-use hint: run this before analyzing unknown encryption functions. However, the trigger scenarios are overbroad ("must prioritize for all binary reverse engineering, disassembly, radare2, debugging questions"), and it does not specify when not to use it or name alternatives among the many r2 sibling tools.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses that execution happens in a sandbox without running the app, requires a real absolute path, forbids fabricating results, and mandates closing the session_id when done. This is valuable behavioral context beyond the schema, though it omits output format and side effects.

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 organized into labeled sections and front-loads the core purpose, but it repeats trigger scenarios (bracket list and 触发场景) and includes decorative tags/emojis. Some sentences are redundant, so not every word 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?

The description gives solid usage context, sandbox behavior, truthfulness rules, and session cleanup guidance. But it does not explain where session_id comes from (e.g., r2_open_file), what the return output looks like, or how address defaults relate to the current position. These gaps matter for an agent invoking 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?

Schema description coverage is 100%, and the schema already explains steps, address, init_regs, and session_id with examples. The tool description adds no parameter-specific detail beyond what the schema provides; the mention of absolute path refers to session context rather than a declared parameter. Baseline 3 is appropriate.

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 uses a specific verb and resource: '在 ESIL 沙箱中模拟执行代码' (simulate execution in ESIL sandbox), and lists concrete use cases such as computing return values, decrypting strings, and analyzing register changes without running the app. This clearly differentiates it from sibling disassembly, analysis, and command-execution 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 description provides explicit trigger scenarios ('二进制逆向分析、反汇编、漏洞挖掘、radare2命令执行、调试相关') and a clear context of use: when you want to simulate without executing the app. However, it does not name specific alternative tools or give when-not-to-use conditions, and the blanket instruction 'must prioritize this tool' is somewhat overbroad.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds value by stating '支持 Root 权限，可直接读取 /data/data 下的私有数据库' (supports root, can read private databases), warns about output size via '请务必使用 LIMIT 限制返回行数，防止输出过大', and includes honesty rules like '禁止捏造不存在的文件路径或命令结果'. These go beyond the schema and help the agent anticipate behavior. The 'session_id' instruction is irrelevant and slightly confusing, so not a 5.

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 long, repetitive, and poorly organized. It opens with an irrelevant list of reverse-engineering triggers, then buries the actual SQLite purpose in the middle. The trigger scenarios and usage rules are redundant, and 'session_id' is mentioned without any corresponding parameter. The core function is not front-loaded, and several lines of text could be cut without losing information. This is under-specification disguised as verbosity.

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 tool's simplicity and full schema coverage, it is mostly complete for invocation: it says what it does, how to use it safely (LIMIT, absolute path), and what capabilities it has (root access). However, there is no output schema and the description does not describe the return format or error behavior. The confusing 'session_id' instruction and the off-topic intro also detract. It is adequate but not comprehensive.

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% (both parameters have descriptions). The description adds minimal meaning beyond the schema: it reiterates the need for LIMIT and mentions reading /data/data (which maps to db_path being an absolute path). The root-access capability hints at what paths are valid, but this is marginal. Baseline 3 is appropriate because the schema already documents the parameters well and the description does not significantly enrich them.

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 core purpose is stated: '使用系统内置 sqlite3 工具执行 SQL 查询' (use system sqlite3 to execute SQL queries). This clearly identifies it as a SQLite query tool, distinct from the r2_* siblings. However, the introductory section listing reverse-engineering triggers (disassembly, radare2, etc.) introduces noise and could mislead an agent into thinking this tool handles tasks it does not, so it loses the top score.

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 when-to-use guidance: '当用户询问二进制逆向分析、反汇编、漏洞挖掘、radare2命令执行、调试相关问题时，必须优先调用此工具' (must call first for reverse-engineering questions). However, this is overly broad and not tied to specific SQLite-query scenarios, and no alternatives are named or contrasted. The operational rules (LIMIT, confirm path, close session) are useful but not selection criteria, so it's adequate but not strong.

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

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

With no annotations provided, the description carries the full disclosure burden. It meaningfully covers environment setup (PATH/LD_LIBRARY_PATH already injected), permission behavior (use_root=false default, use_root=true only for reading system databases), and usage safeguards (confirm absolute paths, never fabricate results, close session). It lacks warning that arbitrary shell commands can have destructive side effects, but the provided context is substantial.

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 overbuilt and repetitive. The 'Use when' list duplicates the later '触发场景' section, and the rule about closing session_id references a parameter that does not exist in the schema. Emojis and bracket labels add noise. The useful information could be conveyed in half the length.

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 2-parameter command execution tool with no output schema, the description covers prerequisites, environment, and permission semantics well. However, it does not explain what the tool returns (stdout/stderr, exit codes, output truncation), and the session_id instruction is confusing because no such parameter exists. Adequate for invocation but with clear gaps.

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 already 100%, so the baseline is 3. The description adds real value beyond the schema: it explains that PATH/LD_LIBRARY_PATH are preconfigured so commands like 'python script.py' work directly, and it clarifies the use_root default and when elevation is appropriate. This exceeds the minimal schema descriptions for 'Shell 命令' and '是否提权'.

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 executes system commands in the Termux environment and gives concrete examples (Python, Node, Curl, SQLCipher). The verb+resource are specific. However, it opens with a reverse-engineering framing and says radare2 command execution should use this tool, which blurs the line with sibling r2 tools 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 provides explicit 'Use when' scenarios and says this tool must be prioritized for reverse-engineering questions. However, it does not distinguish this tool from the many r2 siblings, and it explicitly instructs using this for 'radare2 command execution' even though a dedicated r2_run_command sibling exists. This is misleading rather than merely incomplete.

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

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

With no annotations provided, the description carries the full disclosure burden and does substantial work: it reveals the exact destination directory, automatic directory creation, automatic +x permission granting, owner correction, and the expected follow-up execution pattern. The main deductions are the inaccurate 'Binary/reverse-engineering tool' categorization and the ghost instruction about closing a session_id when no such parameter exists in the schema. The disclosed side effects go well beyond what the schema could convey.

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 bloated and repetitive: the trigger scenario is stated twice in nearly identical terms (the opening 'Use when' list and the 【触发场景】 block), and the 'session_id must be closed' sentence is irrelevant given the parameter list. The genuinely useful information (save location, auto-permissions, run-after pattern) is buried under boilerplate, and the description leads with a misleading category label rather than the actual function. This is over-specification with noise, not 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?

For a simple save tool the operational essentials are covered: destination directory, automatic side effects, and the post-save run command. But with no annotations and no output schema, the description should also clarify return/error behavior and overwrite semantics, which are absent. More critically, the internal inconsistencies — pure filename vs. absolute path, and the phantom session_id instruction — leave an agent genuinely uncertain about how to construct a correct call. Adequate but with clear gaps.

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 description coverage is 100% (content = code content, filename = pure filename), so the baseline is 3. The description adds modest value by clarifying that the filename lands inside the sandbox directory and that content is expected to be runnable code (python filename.py). However, the 'confirm the absolute path of the target file' rule actively contradicts the schema's definition of filename as a pure name, which prevents a higher score.

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 states a specific verb+resource — save code to the AI sandbox directory (/data/data/com.termux/files/home/AI) — and names concrete behaviors (auto-create directory, auto-chmod +x, auto-fix owner). However, it opens by mislabeling the tool as a 'Binary/reverse-engineering tool' and later references session_id cleanup, which muddies what the tool actually is and blurs its boundary with the r2_* siblings. The core purpose is clear, but the framing is noisy enough to keep it from 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 usage context: a trigger list (binary analysis, disassembly, radare2, debugging, vulnerability research) and an explicit pairing with the sibling termux_command ('after saving, immediately run termux_command(...)'), plus an anti-fabrication rule. However, the 'must prioritize this tool' mandate for disassembly/radare2 questions misroutes the agent away from more appropriate siblings like r2_disassemble or r2_run_command, and the precondition that the user provide an absolute target path directly contradicts the schema's 'pure filename' parameter. Explicit guidance exists, but parts of it are misleading.

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