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

With no annotations, the description carries the full burden. It usefully discloses that an APK path is required and that a manual on-device step follows, but it says nothing about return values, error behavior, or whether the device serial/adb connection must already be established. Partial behavioral context only.

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?

Two tight sentences that front-load the core action before the follow-up note. No wasted text, though the trailing on-device instruction is more workflow guidance than an invocation directive.

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 preparation tool with no annotations and no output schema, the description covers the essential step and the manual follow-up, but omits prerequisites (device must be listed/connected), the meaning of serial, and what success produces. 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 coverage is only 50%: blackdexApkPath is documented in both schema and description ('需提供其 APK 路径'), but the serial parameter is undocumented in the schema and untouched by the description. The description also does not explain how serial interacts with 'on the device'.

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 names a concrete action ('在设备安装并启动 BlackDex', install and launch BlackDex on the device) and scopes itself as the first step of the no-root unpacking path, which distinguishes it from blackdex_pull and the frida_* siblings. The verb+resource is specific enough that an agent knows this is a setup stage rather than the actual unpacking.

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 signals ordering ('免 root 方案第一步') and what comes next (manually select the target app to unpack), which gives implied usage context. However, it never names the alternative path (frida_prepare) or states prerequisites/exclusions, so the agent must infer when to choose this over the rooted workflow.

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 operation is a device-to-host transfer over previously dumped dex output, which is useful non-obvious context. It omits whether the pull is read-only or overwrites, how files are named/placed, and what happens if no dump exists.

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?

A single sentence, front-loaded with the pipeline position (‘第二步’) and the operation, with zero redundant or filler text.

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 3-parameter tool with no annotations, no output schema, and 0 required parameters, the description is thin: it never says what is produced (file list? paths?), what outDir/serial control, or what error conditions mean. An agent could pick this tool but not call it confidently.

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 only 33% (only targetPkg is described in the schema) and the description never mentions outDir or serial. The implied destination ('拉回本机') is the closest it comes to explaining outDir, so it does not compensate for the coverage gap.

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 gives a specific verb (拉回/pull) and resource (BlackDex 脱壳 dump 出的 dex) plus the data-flow direction (from device to local machine). It is distinguishable from siblings like pull_apk or frida_unpack because it names BlackDex specifically, though it never explicitly contrasts itself with them.

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?

"免 root 方案第二步" implies it must run after blackdex_prepare, which is genuine sequencing guidance. However, there is no explicit statement of prerequisites (device connected, dump already performed) nor any when-not/alternative routing versus pull_apk or frida_unpack.

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, so the description carries the full burden. It usefully discloses the side effect that passing pkg triggers an automatic APK pull from the device, which is a meaningful behavioral trait. But it omits safety profile (read-only?), device state requirements, and expected output/confidence, leaving notable gaps for a no-annotation tool.

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?

Two tightly packed sentences with zero waste: purpose and vendors front-loaded, then the input modes. Every clause 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?

No output schema and no annotations, so the description should say more about what a result looks like (detected vendor, confidence, unpacked/not) and what 'serial' does. It covers the input story well but leaves the return and device-targeting aspects thin.

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 67%; the description clarifies the pkg-vs-apkPath distinction (pkg pulls first, apkPath is local), reinforcing the schema. It adds no meaning for the undocumented 'serial' parameter, which is unexplained in both schema and description.

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+resource: identifies whether an APK is packed/hardened and names the packer vendor (360/Tencent/Bangbang/爱加密). An agent can tell this is a detection tool, not an unpacking tool like static_unpack, though the description never explicitly contrasts itself with those 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?

Explains the two invocation modes (local apkPath vs pkg that auto-pulls from device), which is genuine usage guidance. However it gives no when-to-use vs alternatives (e.g., pull_apk then this, or static_unpack) and no prerequisites such as needing a connected device.

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 behavioral burden. It says nothing about whether existing output is overwritten, whether the write requires particular permissions, or what the result of a large multi-dex directory looks like, so an agent cannot predict 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?

Two short sentences with the core purpose front-loaded and no wasted filler. It is compact, though the second sentence is largely a restatement of the schema's dexInput description.

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 two-parameter decompilation tool with full schema coverage and no output schema, the description is minimally adequate. It stays silent on output behavior and side effects, which matters more here because no annotations compensate.

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 both parameters are already documented there, and the description only restates that dexInput accepts a file or a directory. The added 'unpacking output directory' example gives slight extra color but no syntax or format detail 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?

States a specific verb and resource: decompile dex into smali, which is unambiguous about the transformation performed. It does not, however, differentiate itself from related siblings like static_unpack or the blackdex/frida unpacking tools that also produce dex artifacts.

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 no explicit when-to-use guidance or mention of alternatives among the many sibling tools. The parenthetical about the 'unpacking output directory' hints at a pipeline position but leaves the agent to infer when this tool is the right next step.

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 disclose the key trait that this requires root (Magisk/su) and that it pushes a binary and launches a server process — real side effects. However, it omits idempotency, what happens if frida-server is already running, failure behavior, and any cleanup semantics.

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?

A single front-loaded sentence that packs purpose, default path, and the root prerequisite with no filler. Efficient, though the parenthetical could be structured more clearly.

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 two-parameter, no-annotation, no-output-schema prep tool, the description covers purpose, default, and the root requirement. It still leaves the device-targeting parameter and the outcome of 'start' unexplained.

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 only 50%; serverLocalPath is documented in the schema, while serial is undocumented in both places. The description adds a default path (tools/frida-server) for the server path, but contributes nothing about how serial selects a device.

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 pair plus resource: pushes and starts frida-server, framed as root-solution preparation. It is distinguishable from the smali/pull/static siblings, though it never names blackdex_prepare, its closest alternative preparation path.

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 the prerequisite 'needs Magisk/su', which tells the agent the device must be rooted, but gives no explicit when-to-use-vs-alternative guidance against blackdex_prepare or other prep tools. Usage is implied rather than directed.

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 burden. It usefully discloses the setup preconditions (root, frida-server, local frida-dexdump), which is the key operational gate. But it omits side effects (frida attach/spawn on a live app), where dumped dex files land, and failure behavior.

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?

Two short sentences: capability first, then prerequisites. Nothing redundant, every clause is load-bearing.

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 5-parameter mutation-ish tool with no annotations and no output schema, the description covers the critical environment prerequisites but leaves outDir, serial, and the result location/format unexplained, so the agent cannot fully anticipate the call's outcome.

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 60% (outDir and serial have no descriptions) and the description adds nothing about any parameter — no default, format, or behavior hints beyond what the schema already says for pkg, spawn, and deepSearch. It does not compensate for the undocumented 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?

"用 frida-dexdump 从内存 dump 已解密 dex" states a specific verb (dump), resource (decrypted dex), mechanism (frida-dexdump, in-memory), and approach label ("root 方案"). This implicitly separates it from static_unpack and the blackdex_* siblings, though no sibling is named explicitly.

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?

Prerequisites are clearly stated (device rooted, frida-server running, frida-dexdump installed locally), and "root 方案" hints at a non-root alternative. However, no sibling is named, so an agent is left to infer when to pick this over static_unpack, blackdex_prepare/pull, or frida_prepare.

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 'list' combined with zero parameters reasonably implies a safe read. However it says nothing about behavior if no devices are connected, whether it starts/relies on an ADB server, or what the status field can contain, so behavioral disclosure is only minimal.

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?

A single front-loaded sentence with no filler; the resource and the key output attribute (device status) are both stated up front.

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 trivial, zero-parameter discovery tool with no output schema, the description covers what is enumerated and what is returned. It leaves the possible status values unspecified, but with no output schema and no parameters this is a minor gap.

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 accepts zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are given.

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 names a specific verb and resource ('列出...安卓设备' / list Android devices) and adds the qualifier that they are ADB-connected and that status is included. This distinguishes it naturally from all siblings (list_packages, pull_apk, frida_*, smali_*), none of which enumerate devices, though it does not explicitly call out that contrast.

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?

Usage is only implied: an agent can infer this is the discovery step before pull_apk/static_unpack/frida_prepare, but the description states no when-to-use, prerequisites (e.g. ADB server running), or alternatives. No explicit routing guidance is 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only the data source and that keyword filtering is possible; it says nothing about return format, whether system/third-party apps are both included, permissions or ADB/adb-server requirements, or result size/ordering.

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?

A single short sentence with zero filler; the core purpose and the filtering capability are front-loaded and nothing is redundant.

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 annotations and no output schema, the description must stand on its own. It is adequate for a trivial two-parameter lister whose schema is fully documented, but it leaves return shape, app scope and device prerequisites unspecified.

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% for both parameters, so the schema already documents serial and keyword. The description merely restates the keyword filter (and omits serial entirely), adding no semantics beyond the structured fields — baseline 3 applies.

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 (设备上已安装的应用包名), so an agent can immediately tell this enumerates installed packages rather than devices or APK files, unlike siblings such as list_devices or pull_apk. It does not explicitly name or contrast any sibling, which keeps it 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?

Usage is only implied: the verb and scope make it obvious this is the enumeration step (e.g. before pull_apk or detect_packer), but there is no explicit when-to-use, no prerequisites (ADB connectivity, serial required for multi-device), and no named alternatives or exclusions.

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 behavioral burden, yet it says nothing about device selection when 'serial' is omitted, whether existing files are overwritten, whether split APKs are written alongside the base APK, or what permissions/adb state are required. It only implies a read/copy operation.

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?

A single short sentence with no filler, front-loading the operation and its include-splits qualifier. Efficient, though minimal.

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 3-parameter tool with no annotations and no output schema, the description omits key operational context: how the target device is resolved (the undocumented required serial behavior), output layout/naming in outDir, and behavior on multi-device setups. It is too thin for a tool that writes files to the local filesystem.

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 67%: pkg and outDir carry descriptions, serial does not. The description adds little parameter detail beyond the schema ('到本机' loosely maps to outDir), so the baseline 3 for a well-covered schema applies, with the serial gap left for the agent to guess.

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 names a specific verb and resource ('拉取...APK', pull APK) plus scope qualifiers ('已安装应用', installed apps; '含 split', including splits; '到本机', to local machine). This is clearly distinguishable from siblings like list_packages or static_unpack, though it does not name an alternative explicitly.

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?

No statement of when to use this versus siblings such as blackdex_pull (which also pulls artifacts from a device) or list_packages. The agent must infer the intended stage in the workflow entirely on its own.

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 behavioral burden. It says the output is class names, but does not disclose whether listing is recursive across subdirectories, what the path format looks like, whether results are paginated/limited, or any permission requirements.

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?

A single tight sentence with the action and the optional filter front-loaded; nothing is wasted.

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 discovery tool with no annotations and no output schema, the description is thin: it omits recursion scope, result format and size, and keyword matching behavior — details an agent needs before invoking 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 50%: smaliDir is documented in the schema, while keyword is not. The description partially compensates by explaining that keyword filters the class list, but it does not specify matching semantics (substring, case sensitivity, regex).

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 clear verb+resource: list all class names under the smali directory. However, it never distinguishes itself from the close sibling smali_search, which also deals with class discovery via keywords, so an agent cannot tell them apart from the text alone.

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 no when-to-use guidance and no mention of alternatives. '可用关键字过滤' hints that keyword is optional, but it does not say when this tool should be chosen over smali_search or smali_read_class.

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 behavioral burden. It implies a read operation but says nothing about what happens on a missing class, whether output is the full method/field source, error behavior, or that smaliDir must come from a prior unpacking/decompile step.

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?

Two tight sentences, front-loaded with the action and then the className format detail. Nothing wasted, though it is extremely terse given the undocumented smaliDir parameter.

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 two-parameter read tool with no output schema the description is roughly adequate, but omitting any explanation of smaliDir and of failure behavior leaves gaps an agent would hit when invoking it.

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 0%, so both parameters rely on the description. It usefully documents the className accepted formats (com.foo.Bar vs com/foo/Bar), adding meaning beyond the bare schema, but smaliDir is left completely unexplained.

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: reading the smali source of a given class. This is distinguishable from siblings like smali_list_classes and smali_search, though those alternatives are never named. Clear purpose, no explicit sibling differentiation.

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?

No statement of when to use this tool versus smali_search, smali_list_classes, or any other sibling, and no prerequisites (e.g., that a dex_to_smali/static_unpack step must run first to produce smaliDir). Only the className format hint is 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 behavioral burden. It discloses the core operation (regex search in smali dir) and return format (file:line hits), but omits details such as read-only safety, recursion behavior, performance/limits, or whether it searches all smali files. Adequate but not thorough.

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?

Two short sentences, front-loaded with the core operation and return format. No wasted words; 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?

Given no output schema, the description supplies the return format. With a simple 4-parameter read tool and 75% schema coverage, an agent has enough to select and invoke it. Minor gaps like truncation behavior or recursion details are not covered, but they are not critical for basic use.

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 75% (flags, pattern, maxResults documented; smaliDir not). The description adds no parameter-level semantics beyond the schema, so the schema does the heavy lifting. Baseline 3 applies.

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 (regex search) and resource (smali directory), and lists concrete analysis use cases (API calls, strings, crypto, permissions). It does not explicitly differentiate from siblings like smali_list_classes or smali_read_class, though the search operation is distinct.

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 names the contexts where the tool is useful (analyzing API calls, strings, encryption, permissions), giving clear usage context. It does not state when not to use it or name alternative sibling tools, so it falls short of an explicit when/when-not/alternatives structure.

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 the real behavioral trait that hardened APKs produce only shell dex — valuable domain context — but says nothing about where output lands, permissions, or whether anything is modified.

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?

Three short, front-loaded sentences that each add information: what it does, how to invoke it, and the hardened-APK caveat. No padding.

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?

Covers purpose and one important caveat, which is the minimum viable for this tool. But with 0% schema coverage and no annotations or output schema, the missing explanation of outDir/serial and of where extracted dex files go leaves real 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 0% across 4 parameters, and the description only explains apkPath and pkg (including that they are alternatives). outDir and serial are undocumented in both schema and description, so half the parameters remain opaque.

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: static unpacking, decompressing an APK to extract all classes*.dex files. The word 'static' implicitly separates it from the dynamic sibling frida_unpack, but no sibling is named explicitly.

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?

Says apkPath or pkg can be supplied (pkg triggers auto-pull), which is useful selection context. The note that hardened APKs only yield shell dex implicitly steers the agent toward a dynamic unpacker, but no alternative tool is named, so the routing is left to inference.

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