re-frida
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_fridaA | Return frida version + native lib presence + USB device list. Soft-skip behaviour: when |
| start_sessionA | Spawn target on the named device and open a Frida session. Args:
session: analyst-chosen session id. The MCP layer keeps a
table mapping session id → live Frida session. Pick
something readable (e.g. Returns:: |
| attach_pidA | Attach to a running process by host PID. Args: session: session id pid: host PID of the target device_id: optional device id; empty means first available Returns:: |
| end_sessionC | Tear down a session, unload scripts, detach from the process. |
| script_loadA | Compile + load a Frida script (JavaScript) into a session. Args:
session: session id
name: a name to look the script up by in subsequent calls
source: the JavaScript source. Frida injects V8 into the
target process; standard Returns:: |
| script_callA | Call method on a loaded script's exports. Args:
session: session id
name: script name (from Returns the return value, or the error string when the JS side threw. |
| enumerate_modulesA | List modules loaded in the session's target process. Returns base address, size, and on-disk path for each module. |
| enumerate_exportsC | List exports of a single module. |
| hook_methodA | Install a tracing hook on The hook captures both arguments (on-enter) and the return value (on-leave) and posts messages back to the Python side for the analyst to consume. Useful for tracing the dispatcher of an encrypted-VM bytecode interpreter, the handler of an MBA-obfuscated arithmetic routine, or the userland callback of an anti-debug check. |
| rpc_exportB | Register a stub Python-side RPC export the script side can call. The function is a reflective shim that returns |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool has a clearly distinct purpose: session management (start, attach, end), environment check, module/export enumeration, script loading/calling, hooking, and RPC export. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., attach_pid, enumerate_modules, script_load), making them predictable and easy to remember.
With 10 tools, the server offers a well-scoped set for Frida-based reverse engineering: covers session lifecycle, exploration, scripting, and hooking without unnecessary clutter.
The tool set covers core workflows (session management, module/export enumeration, script injection, function hooking, RPC). Lacks tools for memory read/write or process listing, but these are secondary for the stated purpose.