frida_inject

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.