Frida MCP: Complete Guide (2026)

TL;DR + what you actually need

Everything to get the Frida MCP server running, in five lines:

Package: frida-mcp on PyPI. Install with pip install frida-mcp. It’s a Python package, not npm.
Prerequisites: Python 3.8+, and Frida 16.0.0+ (it pulls the frida bindings in). A device or local process you are authorized to touch.
Claude Code install: claude mcp add frida frida-mcp (after the pip install puts frida-mcp on your PATH).
What it does: exposes Frida’s device, process, and scripting surface as MCP tools — attach, hook, inject JavaScript, read results.
Rule zero: only instrument software you own or are explicitly authorized to test. This is a dual-use tool; the responsibility is yours.

Legitimate use only

Frida is a mainstream security-research and debugging tool. This guide stays inside authorized research: your own apps, engagements with written permission, and app-hardening validation. It is not a guide to attacking software you don’t own, bypassing licensing, or piracy.

The server is open-source (MIT), built by dnakov on the official MCP Python SDK. The rest of this guide explains the pieces, the tools, the boundaries, and the gotchas.

What it is, in one line

Frida MCP is a Model Context Protocol server that exposes Frida’s dynamic instrumentation — attach to a live process, hook functions, inject JavaScript, inspect and modify memory — as tools an AI agent can call. MCP is the JSON-RPC wire format that lets any LLM client talk to any tool server; if that’s new, start with our What is MCP guide.

Frida itself, in its maintainers’ words, is “Greasemonkey for native apps”: it injects a QuickJS engine into a target process so your JavaScript runs inside it with full access to memory and the ability to hook and call native functions. Frida MCP is the thin bridge that lets Claude drive that engine instead of you typing into a REPL.

Why it exists

Reverse-engineering and app-security work is a loop of small, repetitive Frida sessions: list the processes, attach to the one you want, write a short Interceptor script, read what it logged, tweak, repeat. Each step is mechanical, and the JavaScript is boilerplate you’ve written a hundred times. That is exactly the kind of loop an agent is good at.

Before this server, an analyst pasting Frida output into an LLM chat and copying suggested scripts back was doing manual glue work. Frida MCP closes that loop: the agent enumerates the device, attaches, generates the hook script, runs it via execute_in_session, reads the messages back, and proposes the next probe — without a human shuttling text between two windows. The maintainer summed up the demo bluntly on Hacker News: “Claude reversing itself using frida.”

Frida’s own documentation lists the legitimate jobs this accelerates: tracing your own app’s API to debug a customer issue without shipping a special build, black-box testing an in-house app, or confirming how your app handles data at rest. Those are the loops worth handing to an agent.

Move past app layer security. This training explores mobile systems down to the kernel.

ARM64 static + dynamic analysis: Ghidra, Hopper, IDA Pro, Frida
AI + MCP servers for reversing and forensic analysis
Audit iOS and Android apps for security vulnerabilities
— 8kSec (@8kSec) May 18, 2026

A signal of where the field is heading, from mobile-security training firm 8kSec (verified): Frida and AI-driven MCP servers now sit side by side in a professional curriculum aimed at auditing apps for vulnerabilities. It’s a third-party post, not a maintainer announcement — the frida-mcp author ships releases and a Show HN rather than a running X account.

The named pieces

Five moving parts. Hold these and every tool call and error message stops being mysterious.

Frida core

The C engine that injects QuickJS into a target process. You reach it through the Python bindings; the MCP server calls those bindings for you.

The MCP server

frida-mcp — the Python process your client spawns over stdio. It registers the tools and translates each tool call into a Frida API call.

Device

Where the target runs: the local machine, a USB-attached phone, or a remote device. The agent picks one via get_local_device, get_usb_device, or get_device.

Session

The live attachment to one process. Created with create_interactive_session; it’s the context execute_in_session runs your scripts inside.

The fifth piece is the script — a snippet of Frida JavaScript (usually an Interceptor.attach on some function) that does the actual hooking. The agent writes it, the session runs it, and its send() calls come back as session messages. The takeaway: the server is thin glue over Frida’s Python API, so most failures trace to Frida itself — the wrong device, a missing agent on the target, or a process you can’t attach to.

Install (pip & every client)

Frida MCP is a Python package. Install it, and it puts a frida-mcp command on your PATH that your MCP client launches:

# requires Python 3.8+ and Frida 16+
pip install frida-mcp

# confirm the command resolved
frida-mcp --help

For the most-searched client, Claude Code, that’s one more line:

claude mcp add frida frida-mcp

Restart the client so it loads the new tool catalogue. The install card below generates the per-client config for Claude Desktop, Cursor, VS Code, Windsurf, and the manual JSON fallback — tap your client, copy, restart. Because this is a PyPI package, run the pip install first so the frida-mcp binary exists; the card’s config just points your client at it.

One-line install · Frida

Open server page

Install

The raw config, if you prefer editing by hand (this is exactly what the Claude Desktop entry writes):

{
  "mcpServers": {
    "frida": {
      "command": "frida-mcp"
    }
  }
}

Targeting a phone rather than the local machine? Frida needs its agent on the device: frida-server running on a rooted Android or jailbroken iOS device, or an app repackaged with frida-gadget. That’s a Frida prerequisite, not something the MCP server installs. Running Claude Code specifically? Our Claude Code client page covers scopes and config locations, and mcp.directory/clients lists every client’s config path.

Smallest end-to-end example

Here is the whole value in one exchange — auditing your own app. Say you want to confirm your macOS app writes secrets to the Keychain and never to a plain file. You tell Claude:

You: Attach to my own app "Notes" on this Mac and log every call
to SecItemAdd for 30 seconds, so I can verify my data-at-rest
handling. Use a throwaway session.

Claude:
  -> get_local_device()               (finds this machine)
  -> get_process_by_name("Notes")     (resolves the PID)
  -> attach_to_process(pid=...)       (attaches to it)
  -> create_interactive_session(...)  (opens a scripting session)
  -> execute_in_session(script=`
       Interceptor.attach(
         Module.getExportByName(null, "SecItemAdd"), {
           onEnter(args) { send("SecItemAdd called"); }
         });
     `)
  -> get_session_messages()           (reads what the hooks sent)

Claude: I hooked SecItemAdd. In the 30-second window your app
called it 3 times on note save. I saw no writes to a plaintext
file in that period. If you want, I can also hook the file-write
path to be sure nothing leaks there.

That last line is the point. The agent didn’t just run a script — it read the results back and proposed the next probe. The manual version of this is six terminal commands and a hand-written hook. Here it’s one sentence, against a process you own, in a session you can throw away.

The tools, grouped

Thirteen tools and three resources. Grouping them by job makes the surface easy to hold in your head. Tool names below are the exact ones the server registers.

Device management

enumerate_devices — list every device Frida can see (local, USB, remote).
get_usb_device / get_local_device — grab the USB-attached device or this machine directly.
get_device — fetch a specific device by its ID, for when more than one is connected.

Process management

enumerate_processes — list running processes on a device. Accepts an optional device ID.
get_process_by_name — find a process by name, case-insensitive and substring-friendly.
attach_to_process — attach Frida to an already-running process.
spawn_process / resume_process — start a process suspended (so you can hook before main), then let it run.
kill_process — terminate a process. Handy, and the one to be most careful giving an agent.

Interactive scripting

create_interactive_session — open a scripting session against an attached process.
execute_in_session — run a Frida JavaScript payload inside that session: hook functions, read memory, call native functions, send() data back. This is the workhorse.
get_session_messages — pull the messages your script emitted, since hooks fire asynchronously.

Resources (read-only context)

frida://version — the Frida version in use.
frida://processes and frida://devices — human-readable process and device lists the model can pull as context without a tool call.

Opinionated takeaway: the real power (and risk) is concentrated in execute_in_session. Everything else is plumbing to reach the process; that one tool is arbitrary code execution inside it. Scope your trust accordingly.

What we got wrong

Three assumptions that cost us time the first time we wired this into an authorized mobile audit. All avoidable.

1. We assumed “attach” would just work on the phone. It didn’t, because frida-server wasn’t running on the device. The MCP server can enumerate a USB device, but Frida still needs its agent present on the target. On Android that means pushing and running the matching frida-server as root; on iOS, a jailbroken device or an app re-signed with the gadget. No agent on the target, no attach.

2. We forgot the messages come back asynchronously. Our first hook “returned nothing.” It hadn’t — the send() calls were queued, and we’d never called get_session_messages. Hooks fire when the target hits the function; you poll for the output. Once we told the agent to read messages after exercising the app, the data was all there.

3. We let the agent enumerate the wrong device. A GitHub issue on the repo captures the exact trap: “enumerate_processes returns process list from Windows.” When you don’t pin the device, the agent can list the local machine while you meant the phone. Be explicit about which device every process and session call targets.

Authorized use only — and the agent footguns

Instrument only what you own or are authorized to test

Your own apps, a penetration test with signed scope, or a bug-bounty target within its program rules. Using dynamic instrumentation to bypass protections, licensing, or DRM on software you don’t own is out of scope here and, in many jurisdictions, illegal.

Frida is dual-use, like a debugger or a network sniffer. The same hook that verifies your app’s Keychain usage can tamper with someone else’s app. The tool doesn’t police intent; you do. Keep a clear line: legitimate research is your code, or code you have written permission to touch. Everything in this guide assumes that line.

Now the part specific to letting an agent drive it. The tool surface includes spawn_process, kill_process, and execute_in_session. That last one is arbitrary code execution inside whatever process the agent attached to. An LLM that misreads your request, or that gets steered by a prompt-injection string hidden in a file or app response it reads, can inject a script you didn’t intend or kill the wrong process. Treat every session as if it can crash the target. Practical guardrails:

Run against a throwaway target. A dedicated test device, an emulator, or a VM — never your daily driver or a production host.
Review scripts before anything sensitive. For high-value targets, read what the agent proposes to execute_in_session before it runs.
Treat hook output as untrusted input. Data the target sends back can itself carry injection payloads; don’t let the agent act on it blindly.
Scope the process list. Pin the device and process so kill_process can’t wander.

There’s a natural guardrail worth knowing too: hardened apps ship Frida detection (a form of RASP) that refuses to run when instrumentation is present. On such targets you won’t get far without a bypass — which, on software you don’t own, you shouldn’t be attempting anyway.

Real workflows

Four authorized-research loops where an agent-driven Frida earns its place. Each assumes the target is yours or in scope, and Frida’s agent is present on the device.

Recipe 1 — Audit your own app’s crypto usage

Ask the agent to hook the crypto and Keychain calls your app makes and report the parameters: “Attach to my app, hook the AES and Keychain APIs, and tell me which accessibility class each secret is stored with.” You get a runtime picture of how your own data-at-rest choices actually behave, not just what the code claims.

Recipe 2 — Validate your anti-tamper / RASP

If you ship anti-tamper protections, confirm they trip. Have the agent attach and attempt a benign hook, then report whether your detection fired and how fast. You’re red-teaming your own hardening — exactly what Frida detection exists to catch.

Recipe 3 — Debug a customer issue without a special build

Frida’s canonical use-case: a bug at a customer site your logs don’t explain. Instead of shipping a diagnostic build, have the agent hook the suspect function in your deployed app and dump its arguments and return values. Fix, verify, remove the hook. No custom binary in the field.

Recipe 4 — Trace your app’s network layer

When your app speaks an encrypted protocol and Wireshark can’t help, hook the calls just above TLS to see the plaintext your own app sends and receives. The agent writes the interceptor, runs it, and summarizes the traffic — useful for confirming you’re not leaking a field you thought you’d dropped.

Common mistakes

“Failed to attach” on a phone

Root cause: no Frida agent on the target. frida-server isn’t running (Android) or the app isn’t gadget-injected (iOS). The MCP server can see the device but can’t attach without Frida’s presence on it.

Hooks “return nothing”

Root cause: you didn’t poll for messages. Hooks fire asynchronously when the target hits the function; the output queues until you call get_session_messages. Exercise the app, then read.

Wrong device’s process list

Root cause: the device wasn’t pinned, so enumerate_processes returned the local machine instead of the phone (a real reported issue). Tell the agent which device every call targets.

Version mismatch

Root cause: the frida-server on the device doesn’t match the Frida version the package pulls in. Frida is strict about this. Keep the device agent and your host Frida on the same major version.

Community signal

The demand shows up in two places: security engineers bookmarking the server, and practitioners already building Frida-plus-LLM agents by hand.

The blue-team community filed it under exactly what it is. A r/blueteamsec post — flaired “low level tools / techniques” — surfaced the project as “A Frida MCP server to enable autonomous AI assistance for Android instrumentation.” That framing, autonomous AI assistance for instrumentation, is the whole pitch in one line.

“Over the past 8 years I've been dealing with lots of requests from clients regarding their mobile apps, usually with pentesting for compliance reasons... I wrote over 50 Frida scripts and walkthroughs which I fed to Claude to create my own Android reverse engineering agent.”

r/SideProject · Reddit

A pentester describing the exact loop frida-mcp productizes — built for authorized, compliance-driven client engagements.

Source

That developer’s agent, fed dozens of Frida scripts, could bypass certificate pinning and root detection on apps they were engaged to test, decrypt AES traffic by writing custom scripts, and map an app’s SDKs — the same work frida-mcp exposes as first-class tools. It’s the clearest proof the workflow is real, not speculative.

“Show HN: Frida-MCP – Claude reversing itself using frida.”

dnakov (maintainer) · Show HN · Hacker News

The maintainer's own launch post. Terse, but it names the payoff: hand Frida to the model and let it drive the analysis.

Source

The contrarian view. Two cautions temper the hype. First, this is not plug-and-play: the r/jailbreak and mobile-RE communities are full of threads on Frida detection and the root/jailbreak gymnastics real targets demand — an agent doesn’t remove that friction, and hardened apps will simply refuse to run under instrumentation. Second, and more pointed: handing execute_in_session and kill_process to a probabilistic model is a footgun. 8kSec, the training firm above, files “offensive AI agents” and “MCP exploitation” under advanced, expert-level material for a reason. Powerful, yes; beginner-safe, no.

Frida MCP vs static tools like IDA Pro

These come up together, and they’re complementary, not competing. The split is dynamic vs static.

Frida MCP (dynamic)

Instruments a process while it runs. You see real arguments, live memory, and actual control flow. Best for “what does it do at runtime?”

IDA Pro / Ghidra (static)

Disassembles a binary without running it. You map structure, find functions, and reason about code paths. Best for “how is it built?”

The real workflow uses both: triage statically to find the function you care about, then confirm dynamically with a Frida hook. There’s an IDA Pro MCP server in the catalog for the static half, and our reverse-engineering-tools skill bundles the tooling an agent needs for this kind of work. If your lane is mobile UI rather than binaries, the sibling iOS Simulator MCP guide covers driving the simulator instead of the process internals. Browse the rest at all MCP servers.

The verdict

Our take

Install it if you already do Frida work — mobile security, app hardening, authorized pentesting — and you want an agent to run the mechanical loop of attach, hook, read, iterate. It’s a clean, MIT-licensed wrapper on the official MCP Python SDK, and it maps Frida’s surface to tools faithfully. Skip it if you’re new to Frida (learn the tool before you automate it), if you need static analysis (reach for IDA Pro or Ghidra), or if you can’t give it a throwaway target and a clear authorization boundary. The power here is real, and so is the responsibility.

Use it if

You do authorized mobile / app security work
You already know Frida and want to automate the loop
You have a test device, emulator, or VM to target

Skip it if

You’re new to Frida and dynamic analysis
You need static disassembly, not runtime hooks
You can’t define a clear authorization boundary

Frequently asked questions

What is the Frida MCP server?

Frida MCP (dnakov/frida-mcp) is an open-source Model Context Protocol server that exposes Frida — a dynamic instrumentation toolkit — as tools an AI agent can call. It lets Claude or another MCP client enumerate devices and processes, attach to a running process, and inject JavaScript to hook functions and inspect memory at runtime. It is built on the official MCP Python SDK and ships as the PyPI package frida-mcp.

How do I install frida-mcp?

Run `pip install frida-mcp`. It requires Python 3.8 or later and Frida 16.0.0 or later, and it installs a `frida-mcp` console command. Then point your MCP client at that command: in Claude Desktop the config is {"mcpServers":{"frida":{"command":"frida-mcp"}}}, and in Claude Code the one-liner is `claude mcp add frida frida-mcp`. Restart the client and the Frida tools appear.

Is it legal to use Frida with an AI agent?

Frida itself is a legitimate, widely-used tool. Whether a given use is lawful depends on authorization. Instrument software you own, or that you have explicit written permission to test — your own apps, a pentest with signed scope, or a bug-bounty target within its program rules. Do not use it to bypass protections, licensing, or DRM on software you do not own; that is out of scope here and often illegal.

Does Frida MCP work on iOS and Android?

Yes, because Frida supports both. The server enumerates USB and remote devices, so the agent can target a phone attached over USB. In practice, iOS usually needs a jailbroken device or an app re-signed with frida-gadget, and Android needs root or a repackaged APK with the gadget. Hardened apps often ship Frida detection that blocks instrumentation without a bypass.

What tools does the Frida MCP server expose?

Thirteen tools plus three read-only resources. Device tools: enumerate_devices, get_device, get_usb_device, get_local_device. Process tools: enumerate_processes, get_process_by_name, attach_to_process, spawn_process, resume_process, kill_process. Session tools: create_interactive_session, execute_in_session, get_session_messages. Resources: frida://version, frida://processes, frida://devices.

How is Frida MCP different from IDA Pro or Ghidra?

Frida is dynamic: it instruments a process while it runs, so you observe real behaviour, live memory, and actual function arguments. IDA Pro and Ghidra are static: they disassemble a binary without running it. They are complementary — most analysts triage statically in IDA, then confirm hypotheses dynamically with Frida. Frida MCP brings the dynamic half into an agent loop.

Can the agent run arbitrary JavaScript inside a process?

Yes. The execute_in_session tool runs a Frida JavaScript payload inside a process the agent has attached to, with full access to memory and function hooking. That is powerful and dangerous. Treat it as remote code execution inside the target: run it against a dedicated test device, emulator, or VM — never your daily driver — and review what the agent injects into anything sensitive.

Glossary

Dynamic instrumentation: Observing and modifying a program’s behaviour while it runs, rather than analyzing its code at rest.
Frida: An open-source instrumentation toolkit that injects a JavaScript engine into native processes on Windows, macOS, Linux, iOS, and Android.
MCP: Model Context Protocol — the JSON-RPC wire format that lets any LLM client talk to any tool server.
Interceptor / hook: Frida’s API for intercepting a function so your code runs on entry and exit — the core of most Frida scripts.
Attach vs spawn: Attach hooks an already-running process; spawn starts one suspended so you can hook before it executes, then resume it.
Session: A live attachment to one process, the context in which execute_in_session runs your scripts.
frida-server / frida-gadget: Frida’s agent on the target: a daemon on a rooted / jailbroken device (server), or a library embedded in an app (gadget).
QuickJS: The small JavaScript engine Frida injects into the target process to run your instrumentation code.
RASP / Frida detection: Runtime app self-protection: code that detects instrumentation and refuses to run. Common in hardened apps.
Static vs dynamic analysis: Static reads the binary without running it (IDA, Ghidra); dynamic observes it while it runs (Frida). Analysts use both.
stdio transport: The MCP transport where the client spawns the server as a child process and talks over stdin/stdout. frida-mcp is a stdio server.

Sources & links

Primary

Repository & README: github.com/dnakov/frida-mcp (MIT, by dnakov)
PyPI package: frida-mcp
Frida official docs: frida.re/docs/home
MCP Python SDK: modelcontextprotocol/python-sdk

Community

Show HN (maintainer): Frida-MCP – Claude reversing itself using frida
r/blueteamsec — A Frida MCP server for autonomous AI Android instrumentation
r/SideProject — Building a Frida-driven Android RE agent for compliance pentests
X / 8kSec — Frida + AI/MCP servers in a mobile-security curriculum

Internal

Static RE

If something here is out of date — a renamed tool, a new install path, a changed prerequisite — email [email protected] or read more on our about page. We keep these guides current.