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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the connection action and protocol, omitting side effects like creating a persistent session, error behavior when the server is unreachable, or the state change implied by 'add'. The description is not misleading but is too sparse.

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 a single sentence, front-loaded with the verb, and contains no unnecessary words. It is appropriately concise for the minimal content it delivers.

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 minimal, with no annotations, no usage guidance, and no explanation of side effects. While an output schema exists, the description alone is insufficient for a connection tool—it should mention prerequisites like frida-server running remotely, the effect on the current session, and its relationship to siblings such as frida_remove_remote.

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%, and the description does not explain the host and port parameters. Although the parameter names are somewhat self-explanatory, the description adds no meaning beyond the schema and fails to compensate for the lack of schema 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 uses the specific verb 'Connect' and identifies the resource as a remote Frida server over TCP, clearly distinguishing it from siblings like frida_remove_remote and frida_detach. It states exactly what the tool does with scope.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of related tools like frida_remove_remote. There is no context about establishing a session or when a remote connection is needed.

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 transparency burden. It only lists parameters and their types; it does not disclose side effects (e.g., whether the process is paused), prerequisites (e.g., Frida server running), or the lifecycle of the attach (e.g., requires a subsequent detach). This is a significant gap for a state-changing 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 concise: a single purpose sentence followed by a bullet list of parameter explanations. There is no wasted text or redundant information; each bullet earns its place. The structure is scannable and easily parseable by an agent.

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 parameter semantics well and the output schema presumably handles return values, but it lacks broader operational context such as when to use attach vs spawn, whether a new session is created, and what happens to the process. For a tool with 6 optional parameters and no annotations, this is a noticeable gap, making it merely 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 description coverage is 0%, and the description fully compensates by clearly explaining each of the 6 parameters. For example, 'identifier: Application bundle identifier' and 'realm: Session realm — native or emulated' add meaning beyond bare property names, plus 'device_id' notes default behavior. Every parameter receives a semantic 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?

The description clearly states the tool's action ('Attach') and target ('running process'), adding specificity via 'by PID or name'. This distinguishes it from siblings like spawn, resume, or kill, meeting the highest bar for purpose clarity.

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 implies usage context (use when you need to attach to an existing process) but provides no explicit when/when-not guidance or mention of alternatives. It is not misleading but relies on the agent to infer the appropriate scenario.

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?

Since no annotations are provided, the description carries the full burden. It discloses that the script is not loaded, that the pid must have an active session, and that the return value is Base64-encoded bytecode. It also explains the behavioral difference between runtimes. This is solid transparency for a compile 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 compact and well-structured: a one-sentence purpose, a clear Args list, and a Returns line. Every element adds value with no redundancy or filler.

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 has three parameters and no annotations, but the description covers the purpose, each parameter, a prerequisite, and the return format. It also mentions that compilation does not load the script, addressing the core behavioral nuance. The presence of an output schema means return details are not required in the description, but it includes them anyway.

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 provides only types and a default for runtime, but no descriptions. The description fully compensates by explaining each parameter: pid (with active session requirement), source (JavaScript source), and runtime (with options and default). This adds complete 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 clearly states 'Compile a script to bytecode without loading it,' which identifies the specific action (compile), the resource (script), and the distinguishing behavior (without loading). This differentiates it from sibling tools like frida_load_script or frida_snapshot_script.

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 clear context: the tool compiles rather than loads, requires an active session, and explains runtime choices (qjs vs v8) with their implications. While it doesn't explicitly name alternative tools, the 'without loading it' phrasing implies when to use it over loading 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?

There are no annotations, so the description must carry the full burden of behavioral disclosure. It merely states the action without specifying side effects (e.g., whether the session becomes invalid, whether the process continues running, or whether any cleanup occurs).

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 a single, concise sentence that is easy to parse and free of verbosity. It earns its place by stating the core action, though it could have used the brevity to add useful context without becoming unwieldy.

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 tool with one parameter and an output schema, the description is still under-specified. It lacks usage context, parameter explanation, and behavioral notes, making it insufficient for an agent to fully understand when and how to invoke 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?

The schema defines pid as an integer, but the description does not explain its meaning or format. While the name implies it is the process ID to detach from, the description fails to clarify that it identifies the process session, leaving room for confusion.

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 (detach) and the target (process session), which distinguishes it from siblings like frida_attach and frida_kill. However, it does not elaborate on what 'process session' means, leaving slight ambiguity about whether it refers to a session object or the process's attached state.

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 guidance is provided about when to use this tool versus alternatives. For example, it does not explain when to detach instead of kill or resume, nor does it mention whether a prior attach or spawn is required.

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 of behavioral disclosure. It only states the action and a prerequisite, without revealing side effects, reversibility, or impact on the session and its child processes. This is insufficient for a mutating 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 concise, with the action stated first and the argument explained in a clear Args block. Every sentence is informative, with no redundant 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?

For a simple one-parameter tool with an output schema, the description covers the core purpose and parameter meaning. It misses some behavioral context, but overall is adequate for 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 description adds meaning to the pid parameter by explaining it as the target process PID and specifying the active session requirement, which goes beyond the schema's bare integer type. This is valuable, but could be more explicit about validation or expected state.

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 disables child gating on a session, specifying the exact action and resource. It differentiates from siblings like enable_child_gating and disable_spawn_gating through the specific term 'child gating'.

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 implies when to use it (when you have an active session) but provides no explicit comparison to alternatives such as disable_spawn_gating or enable_child_gating. The prerequisite 'must have active session' gives some context but not a full usage 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 provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining any side effects, prerequisites, or what 'disabling spawn gating' entails. There is no mention of device requirements, state changes, or reversibility, leaving the agent without critical 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 extremely concise, consisting of two short sentences that lead with the core purpose before explaining the parameter. No unnecessary or repetitive information is included, making it well-structured and easy to 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?

The description covers the essential purpose and parameter but omits broader context such as the operational impact of disabling spawn gating. While the presence of an output schema means return values are not needed, the lack of annotations and exclusions makes the description only minimally complete for a device-affecting operation.

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 description adds meaningful context for the sole parameter device_id by explaining it as the 'Target device' and clarifying that the default is used when omitted. This goes beyond the schema, which only indicates null default, and compensates for the lack of schema descriptions (0% coverage).

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 ('Disable spawn gating') and the resource ('on the device'), which is specific and distinguishes it from the sibling tool frida_enable_spawn_gating. The purpose is unambiguous and directly reflected in the tool name.

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 no guidance on when to use this tool versus alternatives. It does not mention any when-to-use or when-not-to-use scenarios, nor does it reference sibling tools like frida_enable_spawn_gating. The usage context is only implied by the verb 'disable' and the tool name, which is not sufficient.

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 the key behavior (child processes suspended) and a precondition (active session). However, it omits details like whether existing children are affected, how to resume, or error behavior, leaving some 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 concise, front-loaded, and contains no fluff. Every sentence adds useful information: purpose, behavior, and parameter 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 a simple toggle operation, the description covers the core behavior and prerequisite. An output schema is present, so return values are not required. It could mention the corresponding disable tool or resume interaction, but overall it's adequately 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?

Schema coverage is 0%, so the description must compensate. It explains that pid is the target process PID and must have an active session, adding meaning beyond the schema's bare integer type.

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 'Enable child gating on a session' and explains the effect on child processes, making the purpose clear. It doesn't explicitly differentiate from sibling frida_enable_spawn_gating, but the verb and resource are specific enough.

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 context that child processes are suspended until resumed and notes that the pid must have an active session. It doesn't mention alternatives or exclusions, but the intended use is implied clearly.

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 burden of behavioral disclosure. It states that newly spawned processes are suspended until explicitly resumed, a key side effect. It could add detail about persistence or interaction with existing processes, but the core behavior is transparent.

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 short and front-loaded: it states the action, explains the effect, and lists the parameter in a clean three-part structure. Every sentence is necessary and contributes to understanding.

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 (one optional parameter, output schema provided), the description covers all necessary aspects: what it does, the behavioral consequence, and parameter semantics. It is complete and self-sufficient.

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 Args section explains device_id as 'Target device. Uses default if omitted', adding meaning beyond the schema's bare default null. This fully compensates for the 0% schema description coverage and clarifies the parameter's purpose and behavior.

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 'Enable' and resource 'spawn gating on the device', clearly distinguishing it from sibling tools like frida_disable_spawn_gating. It also explains the effect of spawn gating, making the purpose unambiguous.

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 clear context for when to use the tool (to enable spawn gating, suspending newly spawned processes). It does not explicitly name alternatives or exclusions, but the behavioral explanation implies its use case well.

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 full behavioral burden. It discloses the need for an active session but does not state whether the operation is read-only, requires special permissions, or how errors are handled. No supplementary annotation context 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?

The description is two short sentences, front-loaded with the action, and the argument list is concise. There is no wasted 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?

An output schema exists, so return values need not be explained. However, the description does not differentiate from the sibling frida_list_exports and does not clarify how an 'active session' is established. For a simple two-parameter tool, this is adequate but leaves ambiguity.

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 the description must compensate. It provides brief definitions for both parameters ('Target process PID (must have active session)' and 'Name of the module to inspect'), adding some context beyond raw names. However, the definitions are terse and nearly restate the parameter names, lacking details on formats or preconditions.

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 clear verb+resource ('Enumerate exports of a specific module') and identifies the target module and PID. However, it does not distinguish from the sibling tool frida_list_exports, which likely has a similar 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?

No guidance is given on when to use this tool versus alternatives like frida_list_exports or frida_enumerate_modules. The only prerequisite mentioned is 'must have active session', but no context is provided for choosing this tool over others.

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 mentions the injection of a helper script and the requirement of an active session, which hints at the underlying mechanism. However, it does not disclose whether the operation is read-only (beyond the name), potential error conditions, or any side effects from injection. This leaves gaps in predictability.

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 compact, front-loads the purpose, and uses a clear Args section. Every sentence earns its place; there is no redundant or filler content, making it easy to scan and understand.

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 essential workflow: injecting a helper script, requiring an active session, and optionally filtering by name. Since an output schema exists, return value details are not necessary. It could mention failure modes or platform constraints, but for a tool of this simplicity, the description is reasonably 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?

Schema description coverage is 0%, so the description fully compensates by explaining both parameters. It notes that pid requires an active session and that name_filter is a case-insensitive substring filter with practical advice to avoid huge result sets. This adds significant meaning beyond the raw schema types.

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 opens with a clear verb+resource statement: 'Enumerate loaded modules in a process.' This directly distinguishes the tool from sibling tools like frida_enumerate_exports (exports) or frida_ps (processes). The purpose is unambiguous and immediately actionable.

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 clearly states the prerequisite of an active session for the PID and recommends using name_filter to avoid large result sets. While it does not explicitly name alternatives or when-not-to-use conditions, the context is sufficient for an agent to determine when to invoke this tool versus similar enumeration 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?

With no annotations provided, the description must carry the full burden. It correctly implies a read-only listing operation, but does not disclose potential return values, behavior when no children are pending, or whether child gating must be enabled. The simplicity of the operation mitigates the gap.

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 extremely concise—two sentences plus a single parameter explanation with no filler. It is front-loaded with the purpose and every word contributes to understanding.

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 low complexity and the presence of an output schema (which likely documents return values), the description is adequate. It explains the state ('waiting to be resumed') and the only parameter. It could mention the dependency on child gating, but the sibling tool names provide sufficient context.

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 no descriptions (0% coverage), but the description's 'Args' section explains device_id as 'Target device. Uses default if omitted.' This adds meaning beyond the schema's bare anyOf/string/null definition, effectively compensating for the schema's lack of detail.

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 ('List') and the specific resource ('pending child processes that are waiting to be resumed'). This distinguishes it from sibling tools like frida_enumerate_pending_spawn, which deals with spawn gating rather than child gating.

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 implies usage in the context of child gating ('waiting to be resumed') but does not explicitly state when to use this tool versus frida_enumerate_pending_spawn or mention any prerequisites. It provides context but no direct 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 must fully disclose behavioral traits. It states the tool lists pending spawned processes but does not specify whether it is a read-only operation, whether it requires spawn gating to be active, or if it modifies the pending queue. This leaves the agent uncertain about side effects and prerequisites.

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 concise and well-structured, with a clear purpose statement followed by a brief parameter explanation. It does not waste words, though the 'Args' block could have been integrated more smoothly. Overall, it is appropriately sized for the tool's simplicity.

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 basic function and parameter, but it omits important context such as the prerequisite that spawn gating must be enabled to have pending spawns. It also does not explain the output format, although an output schema exists. For a simple list tool, this is adequate but leaves gaps for an agent unfamiliar with Frida conventions.

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 for device_id has 0% description coverage, but the description adds 'Target device. Uses default if omitted.' This clarifies the parameter's purpose and default behavior, which is sufficient given the single optional parameter. The description directly compensates for the lack of schema-level documentation.

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 'List' with a clear resource 'pending spawned processes that are waiting to be resumed.' This clearly distinguishes it from the sibling tool 'frida_enumerate_pending_children' by focusing on spawned processes rather than child processes. The name and description together unambiguously convey the tool's 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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention that spawn gating must be enabled, nor does it contrast with sibling tools like 'frida_enumerate_pending_children.' The usage context is only implied by the tool's name and the description of pending processes.

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 states the core behavior but omits important details like side effects, reversibility, or what happens to the script after detaching (e.g., can it still be unloaded? does it become independent?). This lack of disclosure is a significant gap for an agent deciding whether to invoke the 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 two lines, front-loaded with the core purpose, and uses a clear 'Args' section to identify the parameter. Every word earns its place; there is no fluff.

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 with an output schema, the description covers purpose and parameter source, but lacks behavioral depth about the implications of eternalizing a script (e.g., how to reverse it, or whether it remains manageable). The missing behavioral transparency makes it not fully complete for an autonomous 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?

The schema only indicates type 'string', but the description adds critical meaning by stating script_id is 'the ID returned by frida_inject'. This tells the agent exactly where to obtain the parameter, going beyond the minimal schema information.

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 specific action ('Eternalize a script') and its purpose ('so it persists after detaching from the session'). This distinguishes it from sibling tools like frida_unload_script (removes) and frida_inject (creates).

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 implies when to use this tool (when you want a script to survive detaching) and gives an important prerequisite: script_id must come from frida_inject. It does not explicitly mention alternatives or when not to use it, but the context is clear.

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 burden of behavioral disclosure. It discloses the default-device fallback behavior, which is useful, but it does not mention potential errors if the device is not found, whether a connection is required, or the return format beyond what the output schema presumably covers.

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 two short sentences, front-loaded with the primary purpose, and contains no filler. Every word contributes meaning, especially the default-device 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?

For a simple getter with one optional parameter and an output schema, the description covers the essential behavior. It lacks explicit guidance on error cases or how to obtain device IDs, but these are minor gaps given the tool's simplicity and the presence of sibling tooling for listing devices.

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 only defines device_id as an optional nullable string with no description. The description adds semantic value by explaining that omission (or null) means the default device is used, which is not evident from the schema alone. It could go further by hinting where to get device IDs (e.g., from frida_ls_devices), but it sufficiently compensates for the 0% schema coverage.

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 ('Get info') and the target resource ('a specific device'), distinguishing it from sibling tools like frida_ls_devices which list devices. It also adds the key behavior of falling back to the default device when no ID is provided.

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 conveys clear context: use it to retrieve info for a named device, or rely on the default when the ID is omitted. It does not explicitly name alternatives or exclusions, but the usage context is unambiguous given the sibling tool frida_ls_devices for listing.

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 of behavioral disclosure. It implies a read-only operation via 'Get' and explains the scope options and default device behavior, which is useful. However, it does not mention potential failure modes, prerequisites, or whether it can return null, leaving some behavioral aspects undisclosed.

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 concise and well-organized, with a clear title and an Args section that lists parameters with explanations. Every sentence serves a purpose, and there is no unnecessary 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?

The description is largely complete for a simple getter tool: it states the purpose, explains the parameters, and the output schema covers return values. However, it could mention prerequisites (e.g., a connected device) or edge cases (e.g., what happens if no frontmost app exists), so it is not fully 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?

The description clearly explains both parameters: device_id as the target device (with default if omitted) and scope as an enumeration with specific values ('minimal', 'metadata', 'full'). This adds substantial meaning over the sparse schema, which only lists the parameters as string/null without any explanation.

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 retrieves details about the frontmost application, which is a specific and distinct resource compared to sibling tools like frida_ls_apps or frida_ps. The verb 'get' and the object 'frontmost application' make the purpose explicit and unambiguous.

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 guidance is provided on when to use this tool versus alternatives. The description only states what it does and lists parameters, with no context about appropriate use cases 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that messages are 'drained', meaning they are removed after retrieval, and clarifies the message source (send() calls). However, it does not explain what happens when there are no messages, whether the call is blocking, or any side effects beyond draining. This is useful but not comprehensive.

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 two short sentences, front-loaded with the action, and every word adds value. It avoids unnecessary detail and is easily skimmable, making it highly concise and well-structured.

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 low-complexity with a single parameter, no nested objects, and an output schema is present (which likely defines return values). The description covers the tool's purpose and core behavior adequately. A note about empty-queue behavior or error handling would improve completeness, but it is not critical for this simple retrieval tool.

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 the description should compensate for the missing parameter detail. The description mentions 'an injected script', which implicitly links script_id to the script context, and the parameter name is self-explanatory. However, it does not explicitly define script_id's role or format, relying on the user's understanding of Frida scripts. This partial compensation earns a mid-range 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 clearly states the tool's action ('Retrieve and drain pending messages') and the resource ('an injected script'), which distinguishes it from sibling tools like frida_post_message (sends messages) and frida_list_scripts (lists scripts). The verb 'drain' adds specificity about the consumption 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 implies usage by explaining that messages are produced by send() calls in the injected JS, suggesting this tool is used to fetch those messages. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context is clear but not fully developed.

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 does so well: it discloses the default runtime (QJS) lacking Java/ObjC bridges, mandates v8 for those cases, and states the return value (script_id). This goes beyond simple 'inject' by revealing important execution context, though it omits potential error conditions or 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 well-organized: one-sentence purpose, prerequisite in bold, an IMPORTANT runtime callout, then Args and Returns. Every sentence earns its place, with no filler. Critical information (runtime limitation) is highlighted 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?

Given moderate complexity and no annotations, the description covers prerequisites, runtime choice, parameters, and return value. It does not explain how the script will be unloaded or potential errors, but it provides enough for correct initial invocation. The output schema also supplements return value understanding, so completeness is strong.

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%, but the description's 'Args' section fully compensates by defining each parameter: pid (target PID), source (JS code), and runtime (with default 'qjs' and explicit note about v8). This adds substantial meaning beyond the bare schema types, making the tool usable without additional docs.

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 opening sentence 'Inject a JavaScript snippet into a process.' uses a specific verb and resource, clearly distinguishing it from sibling tools like frida_inject_library_file/blob which inject native libraries. The tool's purpose is unambiguous and immediately understood.

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 an explicit prerequisite ('must already have an active session (use frida_attach first)') and detailed runtime guidance, including when to use v8 for Java/ObjC APIs. However, it does not explicitly contrast with alternative injection tools (e.g., native library injection), so it stops short of full 'when-not' 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?

No annotations are provided, so the description must disclose behavioral traits. It only says 'Inject' without mentioning side effects, prerequisites, or potential risks. There is no information about whether the injection is reversible, what happens on failure, or if it requires an active session. This is a significant gap for a tool that modifies a running process.

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 concise and well-structured: a one-sentence purpose followed by a clear bulleted list of arguments. Every line adds value with no redundant 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?

The description covers the purpose and all parameters, and an output schema exists, so return-value details are not required. However, it lacks critical context about the execution environment (e.g., whether the process must be attached first) and the behavioral consequences of injection. For a tool of this complexity and risk, some additional context is warranted.

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 no parameter descriptions (0% coverage), but the description compensates fully by explaining each parameter: pid, blob_base64, entrypoint, data, and device_id, including the default behavior for device_id. This adds meaningful semantics beyond the bare 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 a specific action: 'Inject a native library from memory (base64-encoded binary) into a process.' This distinguishes it from the sibling tool frida_inject_library_file by explicitly noting the 'from memory' mechanism, making the purpose clear and 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?

The description implies usage through the phrase 'from memory (base64-encoded binary)', which signals when to use this tool over frida_inject_library_file. However, it does not explicitly name alternatives or state exclusions. The context is clear but not fully explicit.

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 bears the full responsibility for behavioral disclosure. It only states the injection action and parameter meanings, omitting side effects, prerequisites (e.g., permissions, process state), or potential risks such as process crashes. For a system-level injection tool, this is a significant gap in transparency.

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 highly concise, consisting of a single-sentence summary followed by a compact, well-formatted argument list. Every element provides necessary information without redundancy. The structure is easy to scan and effectively front-loads 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?

The existence of an output schema reduces the need to describe return values, and parameter coverage is solid. However, the description lacks essential context for a complex operation: it does not specify when to use this over sibling tools, what errors might occur, or what happens to the process after injection. This leaves the agent with gaps in understanding the full scope of the tool.

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 description thoroughly explains all five parameters in the 'Args' section, adding meaning beyond the bare schema types. For example, 'path' is clarified as an absolute path on the device, 'data' as a string argument passed to the entrypoint, and 'device_id' as optional with a default. This is especially valuable given the schema has 0% description coverage for 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's action: 'Inject a native library file (.so/.dylib) into a process.' This uses a specific verb and resource, and the word 'file' distinguishes it from the sibling tool frida_inject_library_blob. The purpose is unambiguous and well-aligned with the tool name.

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 implies the primary use case (injecting a library from a path) but does not explicitly mention when to use this tool over alternatives like frida_inject_library_blob or frida_inject. There is no exclusionary guidance or alternative comparison, so the agent is left to infer from the name and context.

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 only states the action 'kill' without noting side effects such as irreversibility, permission requirements, or impact on the Frida session. Error handling behavior is also not mentioned.

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 a single sentence with no wasted words, making it highly concise. However, it is extremely minimal and lacks any structured detail like parameter descriptions or examples, which would make it more helpful without losing 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?

For a destructive operation with no annotations and an unknown output schema, the description is too sparse. It fails to explain device_id, potential errors, or prerequisites. Given the many sibling tools, more context is needed to guide correct selection and 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 description references 'PID' which maps to the pid parameter, but the optional device_id parameter is completely unexplained. With 0% schema description coverage, both parameters need description-level explanation, and only one is partially addressed.

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 'kill' and the target 'process' by PID, which is specific and unambiguous. It distinguishes itself from sibling tools like frida_detach (which detaches without killing) and frida_spawn (which creates a process).

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 kill versus alternatives such as frida_detach or frida_resume. No conditions, prerequisites, or exclusions are mentioned, leaving the agent to infer appropriate usage.

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 disclose behavioral traits. It only states 'List RPC exports' and provides the arg origin. No mention of potential side effects, permissions, error handling, or response format (though output schema exists). It does hint that the script must be injected, but this is 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?

The description is very concise, using two short sentences. The Args section is structured and the content is directly relevant, with no wasted words.

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 simple (one param) and there is an output schema to cover return values. The description covers the basic operation and parameter origin. However, it lacks guidance on usage context (e.g., when to use frida_rpc_call to invoke exports) and error scenarios, making it adequate but not 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 schema provides only a type and required status, with no description. The description adds that script_id is the ID returned by frida_inject, which tells the user where to obtain it. However, other aspects like format or constraints are not covered.

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 lists RPC exports from an injected script, using a specific verb and resource. It distinguishes from siblings like frida_rpc_call and frida_inject by implying the read-only listing role, though it doesn't explicitly name 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?

It implies the tool is used after frida_inject, as the script_id is described as returned by that call. However, it doesn't explicitly state when to use this over alternatives or mention any exclusion scenarios.

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 convey behavioral traits. It states a list operation, which inherently suggests non-destructive read-only behavior, but it does not disclose return format, prerequisites like an active session, or behavior when no scripts are active. For a simple listing tool, this is adequate but not rich.

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 a single, focused sentence of eight words, front-loaded with the verb and object. Every word earns its place, and there is no redundant 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 has no parameters and an output schema exists, the description is largely complete for basic usage. However, it lacks mention of prerequisites or differentiation from related tools, which is a minor gap for an agent deciding when to invoke this tool.

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 has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific details because none are needed.

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 'List' with a clear resource 'active script IDs', making the tool's function immediately obvious. It also distinguishes from sibling tools like frida_list_sessions, which lists sessions rather than scripts.

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 implies usage when script IDs are needed, but it does not explicitly state when to use this tool versus alternatives such as frida_list_sessions or frida_get_messages. No exclusions or alternative references 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?

No annotations are provided, so the description carries the burden of transparency. It states the action and result (PID listing) but does not disclose additional behavioral traits such as whether sessions are scoped to the current device, whether the operation is side-effect free, or what happens when no active sessions exist. The simple read-only nature is implied but not explicit.

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 a single, focused sentence that immediately states the action and subject. It is concise with no wasted words, and the key information is 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?

For a zero-parameter list tool with an output schema, the description is largely sufficient: it names what is listed and the output format (PIDs). However, it could be more complete by clarifying what constitutes a 'session' in the Frida context and whether it applies to a specific device, which would help an agent understand the tool's scope.

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 has zero parameters, so there are no parameter meanings to add. Per guidelines, a zero-parameter schema receives a baseline score of 4, and the description correctly does not need to elaborate on 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 uses the specific verb 'List' and resource 'active session PIDs', clearly stating what the tool does. It distinguishes from sibling tools like frida_ps (list processes) and frida_ls_apps (list applications) by focusing on sessions.

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 alternatives, nor any mention of prerequisites such as having established sessions via attach or spawn. The description provides no context for selection among 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?

With no annotations, the description carries the transparency burden. It discloses return values (identifier, name, PID) and scope-dependent behavior (full includes version/build), which is useful context. However, it does not mention potential error conditions or device connection behavior beyond using a default device.

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 compact and well-structured: a one-sentence summary, return value note, and bulleted parameter details. Every sentence serves a purpose, and the format is easy to scan.

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 adequately covers purpose, parameters, and return values for a simple list tool. However, it does not explicitly distinguish frida_ls_apps from frida_ls_apps_running, nor fully define the 'minimal' and 'metadata' scope values, leaving minor gaps in tool-selection context.

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%, but the description thoroughly explains all three parameters, including scope enum values and defaults. This fully compensates for the sparse schema, making parameter usage clear.

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 ('List') and resource ('installed applications'), and the parenthetical 'frida-ls equivalent' adds clarifying context. It also specifies the return fields, which distinguishes it from working with other Frida 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 implies it should be used to list installed applications, but it does not explicitly contrast this with sibling tools like frida_ls_apps_running or provide exclusion criteria. No 'when to use' or 'when not to use' guidance is given beyond the purpose statement.

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 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.

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

With no annotations, the description carries the full burden. It discloses that the tool lists local, USB, and remote devices, which is useful behavioral context. However, it does not mention any prerequisites (e.g., Frida server running), potential side effects, or return format, leaving some opacity for a read-only 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?

The description is a single sentence, front-loaded with the action and scope, with no unnecessary words. It earns its place entirely.

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 simple listing tool with zero parameters, and the description covers its core functionality. The presence of an output schema covers return values, so the lack of explicit output description is not a gap. It could mention prerequisites, but for a straightforward list, it is 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?

The tool accepts zero parameters, and schema coverage is trivially 100%. Per rubric baseline for 0 params, a score of 4 is appropriate since there are no parameter details to clarify.

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 'List' with a clear resource 'Frida devices' and enumerates types (local, USB, remote). This distinguishes it from sibling tools like frida_get_device (which fetches a specific device) and frida_add_remote (which adds a remote device).

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 implies usage for enumerating available devices, but it does not explicitly state when to use it versus alternatives or provide any exclusions. Sibling tools like frida_get_device suggest a more targeted use case, but no direct comparison is offered.

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 of behavioral disclosure. It only states 'change memory protection flags' without revealing side effects, permission requirements, reversibility, or the meaning of the operation on a running process. This is insufficient for a mutation 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 a single efficient sentence with no filler words. It is concise and front-loaded, though the extreme brevity borders on under-specification.

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 having an output schema, the tool has four parameters with zero description coverage and no annotation safety info. For a memory-mutating operation, the description omits critical context like address format, protection value implications, and process requirements, making it inadequate 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?

Schema description coverage is 0%, and the description does not compensate by explaining any of the parameters. It does not mention pid, address, size, or protection beyond the generic phrase 'protection flags', providing no semantic value beyond the raw 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 uses a specific verb ('change') and resource ('memory protection flags'), clearly distinguishing it from sibling tools like memory_read and memory_write. It could elaborate on what the change entails, but the core purpose is 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?

No guidance is provided on when to use this tool versus alternatives, nor are prerequisites or context mentioned. The description simply states the action without qualifying situations where it is appropriate or inappropriate.

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 transparency burden. It reveals the read-only nature and active-session requirement, but does not disclose failure behavior, permission needs, or effects of invalid addresses.

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, front-loaded with the purpose, and uses a clean Args block. Every sentence carries useful information with no filler.

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 read operation, the description covers all parameters and the active-session prerequisite. Since an output schema exists, the lack of return-value explanation is acceptable, though edge-case guidance (e.g., invalid address handling) is absent.

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 description adds substantial meaning beyond the bare schema types: PID must be a process with an active session, address is a hex string with an example, and size is the byte count. This fully compensates for the 0% schema description coverage.

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 'Read bytes from process memory' clearly states the tool's action and target resource. It is specific enough to distinguish from write/scan/protect, though it does not explicitly differentiate itself from sibling memory 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 implies usage through its purpose and notes a prerequisite ('pid must have active session'), but it does not explicitly state when to prefer this tool over alternatives like frida_memory_scan or frida_memory_write.

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 discloses the active-session prerequisite and address/pattern formats, but it does not state whether the scan is read-only, what it returns (e.g., list of matches), or potential side effects like blocking or performance impact. This is minimal behavioral disclosure.

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 concise: a single purpose statement followed by a compact Args list. Every sentence adds value, and the structure is easy to scan. There is no redundant 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?

All parameters are explained and prerequisites are noted, which is good for a 4-required-param tool. The presence of an output schema likely covers return-value details, so the description doesn't need to explain that. It lacks explicit behavioral context (like no-match behavior), but overall it is reasonably complete for the tool's complexity.

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 no descriptions for parameters, but the description provides essential semantic details for all four: pid (must have active session), address (hex string), size (number of bytes), and pattern (Frida-style with an example and wildcard '??'). This goes well beyond the bare schema and is crucial for correct invocation.

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 ('Scan process memory for a byte pattern') with a clear resource (process memory) and target (byte pattern). This distinguishes it from sibling tools like frida_memory_read and frida_memory_write.

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 implies usage (use when you need to search for a pattern in memory) and notes the prerequisite that the PID must have an active session, but it doesn't explicitly mention when not to use it or suggest alternatives. There is no clear exclusion or comparison to 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the precondition of an active session, but it does not mention that writing to process memory is potentially destructive, irreversible, or could crash the target process. There is no information about permissions, error handling, or side effects beyond the basic write action. This is significant for a mutation 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 concise and well-structured: a one-line purpose statement followed by a clear list of arguments with explanations and examples. Every sentence adds value, and the information is front-loaded with the action. No unnecessary verbosity or 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?

The tool has a simple parameter set (3 params, no nested objects) and an output schema, so return values are covered by that schema. The description covers the essential action and all parameters, but it lacks important behavioral context such as the risk of memory corruption or the need for appropriate permissions. For a tool that modifies process memory, this incompleteness could lead an agent to misuse it without understanding the consequences.

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 provides only types (integer, string), so the description must compensate. It does so effectively by explaining each parameter: pid is the target process PID, address is a hex address string with an example, and hex_data is hex-encoded bytes with an example. It also adds the requirement of an active session for the PID. While it doesn't cover every possible constraint (e.g., address alignment or data length limits), it provides solid semantic meaning for all three 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's action with a specific verb and resource: 'Write bytes to process memory.' This distinguishes it from sibling tools like frida_memory_read (reads memory) and frida_memory_scan (scans memory), making the purpose completely unambiguous.

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 implies usage: when you need to write bytes to a process's memory, use this tool. It provides a key prerequisite ('must have active session') but does not explicitly mention alternatives or when not to use it. The tool's purpose and context make it obvious for the intended use case, but the lack of explicit exclusions or comparison to sibling tools is a gap.

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 must carry the full burden of disclosing behavior. It only lists arguments and does not mention what happens on success/failure, whether it is asynchronous, if there are prerequisites beyond an existing injection, or any side effects. The description adds minimal behavioral context beyond the tool's name.

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 extremely concise: a one-sentence purpose followed by a brief argument list. Every word contributes value, and it is front-loaded with the core action. There is no redundant or repetitive 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?

The tool is simple with 3 parameters and an output schema that likely covers return values. The description covers the essential meaning of each parameter and the core purpose. It does not discuss edge cases or detailed behavior, but for a straightforward message-posting tool this is sufficient. It is slightly incomplete regarding usage prerequisites beyond the script ID origin.

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 the description must compensate. It does this effectively by explaining each parameter: script_id as the ID from frida_inject, message as JSON-serializable, and data as optional base64-encoded binary. This adds meaning beyond the bare schema properties, though it could be slightly more detailed about message format or constraints.

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 function with a specific verb and resource: 'Post a message to an injected script.' This distinguishes it from siblings like frida_inject (injects a script) and frida_get_messages (retrieves messages). The action is unambiguous and accurately reflects the tool's name.

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 implies usage context by noting that script_id is the ID returned by frida_inject, which tells the agent to use this after injection. However, it does not explicitly state alternatives or when not to use the tool, such as comparing with frida_get_messages or frida_rpc_call. The context is clear but exclusions are absent.

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 return format (PID and name), the full scope adds path/user/ppid/started, and device_id defaults when omitted. This is adequate for a read-only tool, though it does not explicitly confirm no side effects or device prerequisites.

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 compact and well-structured: a one-line purpose, a return-value sentence, and a clear parameter list. No redundant information; 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?

The description covers return format, parameter semantics, and scope options. It could be more explicit about what 'minimal' and 'metadata' scopes return beyond full, but the output schema likely fills in the remaining details for this simple tool.

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%, but the description fully compensates by explaining each parameter: device_id uses default, scope has enumeration values with full behavior described, and pids is an optional filter. This adds deep semantic value beyond the bare schema types.

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 lists running processes on a device, using a specific verb and resource. The 'frida-ps equivalent' reference and distinction from sibling tools like frida_ls_apps or frida_get_frontmost_application make the purpose unambiguous.

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 implies when to use the tool (when you need to enumerate processes) and provides usage context via scope and pids parameters. However, it does not explicitly exclude alternatives or reference sibling tools, so it lacks explicit when-not-to-use 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?

With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation via 'Returns', but does not explicitly state whether it alters state, requires special permissions, or behaves differently for invalid device IDs. This lack of disclosure is a significant gap for a system query 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 extremely concise and front-loaded, with only two short sentences. The first sentence conveys the primary purpose, and the second is a brief parameter note. No wasted words.

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?

While an output schema exists (and thus return values are structured), the description is vague about the exact contents of the dictionary. It does not mention potential error behavior or device availability. For a simple query tool, this is acceptable but not 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 description adds meaningful context for the only parameter: 'device_id: Target device. Uses default if omitted.' This explains the purpose and default behavior, exceeding the schema's bare type/default information. For a single parameter, this is adequate, though not exhaustive.

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 'Returns a dictionary of information about the host system', which is a specific verb and resource. It clearly distinguishes from siblings like frida_ps or frida_ls_apps by focusing on system parameters. However, it does not elaborate on what 'system parameters' exactly includes, preventing a perfect 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or alternative tools that might be more appropriate. It only states what the tool does, not when 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?

No annotations are present, so the description carries the full burden. It only states the action without disclosing side effects, prerequisites (e.g., whether the server must be connected), error behavior, or whether the remote device is removed from the manager.

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 a single concise sentence with no redundancy, earning high marks for 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 operation, the description is minimal but lacks behavioral context about what happens on disconnect (e.g., removal from device list) and no parameter semantics. With no annotations, it feels incomplete for an agent to invoke 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 input schema has a `host` string and `port` integer with default 27042, but the description provides no explanation of these parameters. Coverage is 0%, and the description fails to clarify that host is the server address and port is the frida-server port.

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 the specific verb 'Disconnect' and the resource 'remote Frida server', clearly indicating the tool's action. It distinguishes from frida_detach by specifying remote server, but it doesn't clarify the relationship to the tool's name 'remove_remote', which may imply removing a configured device rather than just disconnecting.

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 explicit guidance is given about when to use this tool versus alternatives. The use case is implied by the description—when a user wants to disconnect from a remote server—but no alternatives or exclusions 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 provided, the description must carry the full burden of behavioral disclosure. It states the core action but fails to mention that this is a state-changing operation, any requirements (e.g., process must be in a suspended state), or potential side effects. It also doesn't clarify whether the process must be attached or spawned by Frida.

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 a single, concise sentence that gets to the point without verbosity. It could be slightly more detailed without losing conciseness, but it is appropriately short for 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?

The tool is part of a Frida lifecycle (spawn, attach, resume, kill), but the description does not explain its role in that lifecycle. Even with an output schema, the description lacks essential context about when a process becomes suspended and how the tool integrates with sibling tools.

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%, and the description does not mention either parameter (pid, device_id). It adds no meaning beyond the schema's type definitions. The description should at least indicate that pid is the target process and device_id selects the device, but it remains silent.

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 names the action 'Resume' and the target 'a suspended process', making the tool's purpose unmistakable. It clearly differentiates from siblings like frida_spawn, frida_attach, and frida_kill, none of which involve resuming suspended processes.

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, what prerequisites are needed (e.g., a process must have been previously suspended), or how it relates to alternatives like frida_kill or frida_detach. The description merely states the action without providing context for decision-making.

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. It discloses the rpc.exports requirement and naming conventions (snake_case vs camelCase), but does not mention return values, error behavior, or potential side effects on the target. This is moderate transparency, sufficient for basic use but not exhaustive.

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 compact, front-loaded with a one-line purpose, and uses a clear 'Args' list for optional details. Every sentence contributes essential information with no filler, making it highly efficient.

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 purpose, prerequisites, and parameter semantics, but lacks any mention of return value, error handling, or async behavior. Given no output schema and no annotations, this omission leaves a meaningful gap for an agent deciding whether and how to invoke the tool.

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?

Despite 0% schema description coverage, the description fully documents all three parameters: script_id is defined as the ID from frida_inject, method includes naming convention guidance, and args are described as positional. This adds significant meaning beyond the bare type definitions 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 clearly states the action ('Call an RPC export') and the target resource ('an injected script'), establishing a specific verb-resource pair. It distinguishes itself from siblings like frida_post_message (messaging) and frida_unload_script (teardown) by focusing on invoking exported methods.

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 specifies a clear prerequisite: the script must expose methods via rpc.exports. It also contextualizes usage by referencing script_id from frida_inject. However, it does not explicitly contrast with alternatives like frida_post_message, so it stops short of full exclusionary 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?

With no annotations, the description carries the full burden. It discloses prerequisites (active session), runtime implications (qjs lacks Java/ObjC, v8 has them), and return type (Base64 snapshot). However, it does not mention side effects, reversibility, or whether the session is modified, which would be useful for a tool that creates a snapshot.

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 compact and well-structured: a one-sentence purpose, a clear Args list with explanations, and a Returns line. Every sentence adds value, with no redundant 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?

Given four parameters and no annotations, the description provides essential context: purpose, prerequisites, parameter meanings, and return format. It could mention error conditions or how the snapshot relates to other tools, but it is sufficiently complete for an agent to invoke 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 coverage is 0%, but the description explains all four parameters in detail: pid (with prerequisite), embed_script (source), warmup_script (optional), and runtime (with values and meaning). This fully compensates for the lack of schema 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 specific action ('Create a snapshot of a script') and its purpose ('for fast future loading'), which differentiates it from sibling tools like frida_compile_script or frida_eternalize_script. The verb+resource combination is unambiguous and not a tautology.

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 implies usage for fast future loading but does not explicitly mention when to use this tool versus alternatives (e.g., compile_script or eternalize_script). It provides context like 'must have active session' and runtime choices, but no exclusions or alternative comparisons.

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 that spawning may time out on Android and suggests a fix, which is valuable. However, it does not mention side effects, return values, or default behaviors like auto_resume default true, leaving some 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 front-loaded with the core purpose, followed by a neatly formatted parameter list and a helpful note. No wasted words; the length is appropriate for the tool's complexity.

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 seven parameters and no annotations, the description covers all parameters, includes a troubleshooting note, and benefits from the existence of an output schema, so return values need not be described. A minor gap is that it does not mention how to obtain device_id or what happens on failure.

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 no descriptions (0% coverage), but the description provides clear explanations for all seven parameters, including types and defaults (e.g., 'default if omitted' for device_id, 'inherit', 'pipe', or 'redirect' for stdio), fully compensating for the schema's lack.

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 the specific verb 'spawn' with a clear resource ('a new process') and notes optional attachment, which distinguishes it from siblings like frida_attach (attach to existing process) and frida_inject. This is a clear, specific statement of 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 clearly states the action and includes a conditional alternative (frida_fix_usap) for Android timeouts, which provides concrete usage context. However, it does not explicitly contrast with frida_attach or frida_inject, so the guidance is implied rather than explicit.

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 full responsibility for behavioral disclosure. It merely states the action without mentioning side effects, failure conditions, or idempotency, leaving the agent uninformed about what happens on invocation.

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?

One short sentence, front-loaded with the verb and resource, no redundancy or unnecessary detail. 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 tool is simple with one parameter, but the description is minimal and does not cover what happens after unloading, errors, or relationship to injection. An output schema exists but is not shown; the description could still explain expected behavior more fully.

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%, yet the description does not explain that script_id refers to the identifier of the previously injected script. The parameter is only named, not semantically defined, forcing the agent to infer its meaning.

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 'Unload a previously injected script' uses a specific verb (unload) and resource (previously injected script), clearly distinguishing it from sibling tools like frida_inject or frida_list_scripts.

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 implies its usage for unloading scripts but provides no explicit guidance on when to use it versus alternatives, or prerequisites like the script being currently loaded.

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