Skip to main content
Glama
boy-offi9-inc

HexForge Gateway

by boy-offi9-inc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

frida_trace

Destructive

Injects a Frida script into a spawned or running app and captures its console output for a fixed time window, making instrumentation results easy to collect.

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. Find targets with frida_list_processes. Requires frida-tools and a matching frida-server on the device.

Input Schema

TableJSON 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.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description earns credit by explaining why: the script executes inside the target app and can modify its behavior and state, and spawn mode launches the app. It also discloses the timeout-then-kill lifecycle and the required frida-tools/frida-server dependency.

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?

Dense but front-loaded: the core action and its non-interactive nature come first, followed by lifecycle, return shape, and prerequisites. The first sentence is long and dash-heavy, but no sentence is filler.

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?

For a complex, destructive, open-world tool with no output schema, the description covers return fields, timeout semantics, prerequisites, and target discovery — everything an agent needs to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds interpretive value: the timeout window is the normal termination path (helping interpret timeoutSeconds) and spawn mode launches the app, complementing the schema's mode enum.

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?

States specific verbs and resources: spawn/attach a process, inject a Frida script, capture its output in a fixed window. It also distinguishes itself from the sibling frida_list_processes and from an interactive Frida session, so an agent can identify the tool without reading further.

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 state rather than a failure, which prevents mis-diagnosis. It lacks explicit when-not-to-use guidance beyond 'not an interactive session', 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.

Deploy Server

Other Tools