omni_mobile_deep

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 largely fails it: it never says whether analysis is static or dynamic, whether anything is written to disk, or what a 'Frida SSL-Pinning & Anti-Debug bypass generator' actually emits. 'Bypass generator' hints at producing scripts or patched artifacts, a side effect an agent should know about before calling. Nothing is said about permissions, sandboxing, runtime requirements, or expected duration for these heavyweight analyses.

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?

It is a single dense sentence, so it is compact and front-loaded with the domain, but it reads as a marketing feature list of tool names rather than operational guidance. The space is spent on enumerating engines and formats that the action enum already encodes, leaving no room for when-to-use or behavior.

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?

This is a five-action dispatcher covering very different pipelines with no output schema and no annotations, so the description should explain what each action returns or at least that outputs differ per action. It provides none of that, nor any note on which parameters apply to which action. For a tool of this complexity the definition is materially under-informative.

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 schema already documents action, target_path, and profile_or_meta, and that sets the baseline at 3. The description adds modest value by listing the exact artifact types that target_path accepts, which helps map an action to the right path. It adds nothing about profile_or_meta or about how the action enum determines which other parameters matter.

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 ('Deep Mobile Reverse Engineering') and enumerates concrete resources and formats: Flutter libapp.so Dart AOT, Hermes .hbc, Unity global-metadata.dat, iOS .ipa/Mach-O, and Frida bypass generation. An agent can tell this is the mobile-artifact analysis tool rather than a generic desktop/native one. It loses a point because it never contrasts itself with near-siblings such as omni_deep_reverse, omni_advanced_native, or omni_modern_unpacker, so the boundary is inferred rather than stated.

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 guidance on when to use this tool versus the many sibling reverse-engineering tools, and no stated prerequisites (e.g. that an .apk must first be unpacked, or that frida_bypass targets a package name rather than a file). The action names imply routing by artifact type, but that is left entirely implicit. No exclusions or alternatives are named.

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