Frida MCP Server

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 states the tool injects and runs a script, implying mutation and potential side effects, but doesn't disclose critical behaviors such as permission requirements, whether it's reversible (e.g., via frida_detach or frida_unload_script), error handling, or performance impacts. The mention of script capabilities (e.g., modify behavior) hints at destructiveness but lacks explicit warnings or constraints.

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 front-loaded, with the core purpose stated in the first sentence and additional context in the second. Both sentences earn their place by clarifying the tool's action and script capabilities. However, it could be slightly more structured by explicitly mentioning prerequisites or linking to sibling tools.

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 complexity of a script injection tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error handling), usage context (e.g., dependencies on other tools), and output details (e.g., what happens after injection, message capture behavior). For a mutation tool in a security context, this leaves significant gaps for an agent to operate safely and effectively.

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 100% description coverage, providing clear details for all parameters (session_id, script, on_message). The description adds no additional parameter semantics beyond what's in the schema, such as script syntax examples or session_id validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents parameters without extra description value.

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 purpose: 'Inject and run a Frida JavaScript script in a process.' It specifies the action (inject and run), target (process), and technology (Frida JavaScript script), distinguishing it from siblings like frida_attach (which attaches to a process) or frida_hook_function (which hooks specific functions). However, it doesn't explicitly differentiate from frida_inject_library, which also involves injection but with libraries instead of 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 provides no guidance on when to use this tool versus alternatives. It mentions what the script can do (e.g., hook functions, intercept calls), but doesn't specify prerequisites (e.g., requires an attached session via frida_attach), exclusions, or comparisons to similar tools like frida_hook_function or frida_inject_library. This leaves the agent without context for tool selection.

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