frida_ls_apps_running

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

No annotations are provided, so the description carries full behavioral disclosure burden. 'List' clearly indicates a read-only operation, and the arg note 'Uses default if omitted' adds helpful default behavior. While it doesn't explicitly say 'non-destructive' or detail failure modes, the safe, query-like nature is clear from the wording. This is adequate for a simple listing 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?

The description is exceptionally concise: one sentence for the purpose plus a compact argument list. Every word contributes value, there is no fluff, and the important information is front-loaded. It is easy to scan and parse.

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 listing tool with an output schema, the description covers the essential aspects: purpose, parameters, and default behavior. It is complete enough for an agent to select and invoke the tool correctly. A slight gap is the lack of explicit alternative guidance, but that is already minimal given the well-scoped purpose.

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 has 0% description coverage, so the description must add meaning. It does: device_id is described as 'Target device. Uses default if omitted', scope is enumerated with 'minimal', 'metadata', or 'full', and identifiers is an optional filter list. These augment the bare type/name information meaningfully, though the exact meaning of scope levels is not elaborated.

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 starts with 'List only currently running applications', which is a specific verb (List) plus a well-defined resource (currently running applications). The word 'only' clearly distinguishes this from sibling tools like frida_ls_apps (which likely lists all apps) and frida_ps (processes). This is a clear, unambiguous purpose statement.

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 does not explicitly state when to use this tool versus alternatives. The phrase 'only currently running' hints at the distinction from frida_ls_apps, but no alternative is named or exclusion provided. The agent must infer usage context from the tool name and sibling list, rather than receiving direct guidance.

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