Skip to main content
Glama

frida_trace

Destructive

Spawn or attach to a process on a device, inject a Frida script, and capture whatever it prints within a fixed time window - not an interactive Frida session: it runs the script, waits timeoutSeconds, then kills the session.

Instructions

Spawn or attach to a process on a device, inject a Frida script, and capture whatever it prints within a fixed time window - not an interactive Frida session: it runs the script, waits timeoutSeconds, then kills the session. Hitting the timeout is the normal way a trace ends (timedOut: true), not a failure. The script runs inside the target app and can modify its behavior and state, and spawn mode launches the app. Returns { target, mode, scriptPath, timedOut, stdout, stderr } where stdout is whatever the script printed (e.g. console.log output) and scriptPath is where the script was saved in the workspace. The full result is also saved as a JSON file in the workspace and its path returned as outputPath, so it can be cited as evidence. Find targets with frida_list_processes. Requires frida-tools and a matching frida-server on the device.

Input Schema

NameRequiredDescriptionDefault
modeNospawn starts the app fresh with the script loaded from the start; attach hooks an already-running process. Default spawn.spawn
scriptYesRaw Frida JavaScript source to inject, e.g. an Interceptor.attach(...) hook that console.logs arguments.
targetYesIn spawn mode, the package name to launch, e.g. "com.example.app". In attach mode, a PID (digits only) or a running process name.
workspaceNoWorkspace name (not id). Created if it doesn't exist, and this call is recorded as a job in its history. Defaults to "default".
deviceSerialNoDevice serial from adb_devices, e.g. "emulator-5554" or "R58M123ABC". Only needed when more than one device is connected; omit otherwise.
timeoutSecondsNoHow long to let the script run before stopping it. Default 15, capped at 60.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.3.7
    • addedInput schema / properties / deviceSerial / description
      Added value: +"Device serial from adb_devices, e.g. \"emulator-5554\" or \"R58M123ABC\". Only needed when more than one device is connected; omit otherwise."
    • addedInput schema / properties / mode / default
      Added value: +"spawn"
    • changedInput schema / properties / mode / description
      Previous value: -"Default spawn"New value: +"spawn starts the app fresh with the script loaded from the start; attach hooks an already-running process. Default spawn."
    • changedInput schema / properties / script / description
      Previous value: -"Raw Frida JavaScript to inject"New value: +"Raw Frida JavaScript source to inject, e.g. an Interceptor.attach(...) hook that console.logs arguments."
    • changedInput schema / properties / target / description
      Previous value: -"Package name (spawn mode) or PID/process name (attach mode)"New value: +"In spawn mode, the package name to launch, e.g. \"com.example.app\". In attach mode, a PID (digits only) or a running process name."
    • addedInput schema / properties / timeoutSeconds / default
      Added value: +15
    • changedInput schema / properties / timeoutSeconds / description
      Previous value: -"Default 15, capped at 60"New value: +"How long to let the script run before stopping it. Default 15, capped at 60."
    • addedInput schema / properties / timeoutSeconds / maximum
      Added value: +60
    • addedInput schema / properties / timeoutSeconds / minimum
      Added value: +1
    • changedInput schema / properties / workspace / description
      Previous value: -"Workspace name (not id) - created automatically if it doesn't exist yet. Defaults to \"default\"."New value: +"Workspace name (not id). Created if it doesn't exist, and this call is recorded as a job in its history. Defaults to \"default\"."
  2. First observedv1.3.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations flag destruction and open-world reach, but the description adds the substance: the script runs inside the target app and can modify behavior and state, spawn mode launches the app, the session is forcibly killed after timeoutSeconds, and frida-tools plus a matching frida-server are prerequisites. It also pre-empts the most likely misread (timedOut as failure).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and the non-interactive limitation, then the timeout caveat, then returns. Dense and mostly waste-free, though the return-shape sentence and the evidence-saving sentence overlap slightly in purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by naming the return fields, explaining that stdout is script output, and disclosing the workspace JSON artifact with outputPath. For a destructive, non-idempotent tool this covers what an agent needs to call and cite it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so mode/target/script/deviceSerial/timeoutSeconds are already fully documented — this is the baseline-3 case. The description reinforces the timeout semantics ('waits timeoutSeconds') but adds no parameter syntax or defaults beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb chain (spawn/attach, inject, capture) plus resource (Frida script on a process) and an explicit scope boundary: 'not an interactive Frida session'. An agent can distinguish this from frida_list_processes or adb_shell immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routes the agent to frida_list_processes for target discovery and clarifies that a timeout is the expected end condition, not an error — a genuine usage-level insight. It lacks explicit when-not-to-use guidance against other execution siblings (adb_shell), so it falls short of 5.

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