Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@frida-mcp Attach to notepad and load script to intercept WriteFile calls"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A minimalist Frida MCP server.
Shortest workflow: Attach → LoadScript → Call/Listen → Unload
Frida corpus is widely trained by most models: Ready to use directly
Minimal toolset: Only 6 tools exposed; less is more, keeping context concise
Related MCP server: Frida MCP
Tool | Purpose |
| Attach Frida to a process (PID or process name). Must be called again after process detach/crash |
| Manually disconnect from the current process and unload all persistent scripts; suitable for use before switching targets |
| Load a persistent Frida JS script. Can define |
| Call an RPC method registered by |
| Fetch and clear the script's |
| Unload and clean up persistent scripts |
From source:
npm install
npm run buildOr download from Releases: Select the archive corresponding to your platform (win-x64 / linux-x64 / macos-arm64) from GitHub Releases, extract it, and use it directly without npm install:
# 解压后会得到 frida-mcp/ 目录
node frida-mcp/dist/index.js# 不带参数启动，由 LLM 通过 attach 工具连接
node dist/index.js
# 或启动时直接 attach 到 PID
node dist/index.js 12345{
"mcpServers": {
"frida": {
"command": "node",
"args": ["e:/mcp-ida-frida/dist/index.js"]
}
}
}Attach Frida to a process. AI MUST call this first, and MUST call it again whenever any other tool reports that the process is detached or crashed.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Process ID (number) or Process Name (string, e.g. 'notepad.exe'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While it mentions re-attachment on detach/crash, it does not disclose error handling, prerequisites like permissions, or whether re-attaching after crash works seamlessly. More detail would improve transparency.
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?
Two efficient sentences. First sentence states the action, second provides critical usage rule. No unnecessary words, and the critical instruction is front-loaded.
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 simple tool (1 param, no output schema), the description covers essential usage and re-usage conditions. Could mention what happens on success or error, but is largely complete for an attach action.
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?
Schema coverage is 100% and the parameter description 'Process ID (number) or Process Name (string, e.g. 'notepad.exe')' adds concrete examples and clarifies the two allowed types, going beyond the schema definition.
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?
Description clearly states 'Attach Frida to a process' with a specific verb and resource. It distinguishes from sibling tools like 'detach' and 'load_script' by focusing on the attachment action.
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?
Provides explicit usage instructions: 'AI MUST call this first, and MUST call it again whenever any other tool reports that the process is detached or crashed.' This tells the agent when to use and when to re-use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a function exported by a persistent script loaded via load_script. If this fails because the process is detached/crashed, call the attach tool again and then load_script before retrying.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | Name of the persistent script | |
| method | Yes | RPC method name | |
| args | No | JSON arguments to pass |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions failure mode (detached/crashed process) but does not describe success behavior, side effects, or permissions.
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?
Two concise sentences, no unnecessary words, front-loaded with purpose.
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?
Adequately covers usage and error handling for a 3-parameter tool without output schema; slightly improved by recovery guidance.
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?
All three parameters have schema descriptions (100% coverage), so description adds no extra meaning beyond the schema.
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 calls a function exported by a persistent script, distinguishing it from sibling tools like load_script and attach.
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?
Provides explicit context that the script must be loaded via load_script first, and offers recovery steps if the call fails due to detached/crashed process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detach Frida from the current process and unload all persistent scripts. Call this when finished with the target or before attaching to a different process. After detach you MUST call attach again before any other tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the main behavioral aspects: it detaches Frida and unloads scripts. It also implies a state change by mandating a re-attach. While it does not detail all possible side effects, the information is adequate for a parameterless tool.
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 extremely concise, consisting of two short sentences. Both sentences provide essential information without any filler. The key action and the crucial post-condition are front-loaded.
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 tool has no parameters, no output schema, and no annotations, the description is complete. It explains what the tool does, when to call it, and what must be done after (re-attach). It also implicitly distinguishes from sibling tools by mentioning attach.
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 tool has no parameters, and the schema coverage is trivially 100%. The description does not need to add parameter information, earning a baseline score of 4 as per guidelines.
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 verb 'detach' and the resource 'from the current process' and specifies that it unloads all persistent scripts. It distinguishes itself from sibling tools like attach, load_script, and unload_script.
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 explicitly states when to use the tool: 'when finished with the target or before attaching to a different process'. It also provides a critical post-condition: must call attach again before other tools. However, it does not explicitly mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve accumulated messages (send(data)) from a persistently loaded script and clear its message queue. Similar to tailing a log.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the running persistent script |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool clears the message queue after retrieval, which is a key behavioral detail. With no annotations, the description provides essential transparency beyond the schema.
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?
Two sentences, no wasted words, front-loaded with the main action. Every sentence adds value.
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?
For a simple tool with one parameter and no output schema, the description covers the core behavior adequately. Could mention error conditions or idempotency, but not necessary for this complexity.
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?
Only one parameter 'name' with description matching the schema. Since schema coverage is 100%, the description adds no additional meaning beyond the schema.
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?
Clearly states the action: retrieve and clear accumulated messages from a persistently loaded script, with a helpful analogy to tailing a log. Distinguishes from sibling tools like load_script and call_rpc.
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?
Implies usage context (after sending data via send(data)) but does not explicitly state when to use or not use, nor alternatives. Adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a persistent background Frida script. Use this to set up hooks that collect data over time or long-running RPC exports. Afterwards, use call_rpc to invoke functions or get_script_output to check logs. If this fails because the process is detached/crashed, call the attach tool again and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique identifier for this script (e.g. 'my_hooks') | |
| source | Yes | Frida JS code. Use `send(data)` to emit logs, or `rpc.exports = { ... }` block for RPC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses persistence and failure scenario but does not explicitly mention side effects like overwriting existing scripts or lifecycle details.
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?
Two concise sentences with no redundancy. Front-loaded with purpose, immediately followed by usage guidance.
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?
Covers purpose, usage flow, and failure recovery. Does not specify return value or synchronous behavior, but these are not critical for a load operation.
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?
Schema descriptions cover both parameters. Description adds value by explaining 'name' as unique identifier and 'source' as Frida JS code with send() and rpc.exports patterns.
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?
Clearly states the verb 'load' and resource 'persistent background Frida script'. Distinguishes from sibling tools by mentioning subsequent use of call_rpc and get_script_output.
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?
Explicitly states when to use (set up hooks for data collection or RPC exports) and provides clear guidance on what to do afterwards and upon failure (reattach).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Securely unload and clean up a persistent script.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the script to unload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the operation is destructive ('unload and clean up') but does not explain what 'clean up' entails, whether it is reversible, or what side effects occur. This is insufficient for an agent to understand the behavioral impact.
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 a single concise sentence that efficiently conveys the core action. It is front-loaded with the key verb and resource, and every word serves a purpose. However, it could be slightly expanded for completeness without losing conciseness.
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 absence of an output schema and annotations, the description should provide complete behavioral context. It fails to mention what the tool returns, if any, or confirmation of success. For a tool with only one parameter and no output schema, this is insufficient.
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 schema already describes the single parameter 'name' as 'Name of the script to unload', and the description adds no additional meaning or constraints. With 100% schema coverage, the baseline is 3; the description does not enhance understanding.
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 action ('unload and clean up') and the resource ('persistent script'), making the purpose obvious. However, it does not explicitly differentiate from the sibling tool 'detach', which may have overlapping functionality.
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 like 'detach' or 'load_script'. It does not mention prerequisites, context, or situations to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0attachcall_rpcdetachget_script_outputload_scriptunload_scriptEach tool has a clear, distinct purpose: attach/detach for lifecycle, load_script/unload_script for script management, call_rpc for function invocation, and get_script_output for log retrieval. There is no overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., attach, load_script, call_rpc), making them predictable and easy to understand.
With 6 tools, the set is well-scoped for the purpose of Frida process attachment and persistent script management. Each tool serves a necessary step in the workflow without being excessive or insufficient.
The tool set covers the core workflow of attaching, detaching, loading/unloading scripts, calling RPC, and retrieving output. However, it lacks support for ad-hoc scripts or advanced Frida operations, which might be a minor gap for some use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
An authenticated remote MCP server for user-owned devices and one-shot capability invocation.
Run and manage H Company's Computer-Use Agents from any MCP client.
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SnowLuma/mcp-frida'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
