Provides dynamic instrumentation for Android processes, enabling spawning, attaching, hooking methods, enumerating modules and exports, and RPC communication.
Provides dynamic instrumentation for iOS processes, enabling spawning, attaching, hooking methods, enumerating modules and exports, and RPC communication.
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., "@re-frida attach to process 1234 and enumerate modules"
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.
MCP server wrapping the Frida dynamic-instrumentation toolkit. Frida injects a JavaScript engine (V8) into a target process and lets the analyst hook arbitrary functions, walk the type graph, and call into the target at runtime.
The MCP layer adds:
a stable session identifier — multiple scripts and hooks can be installed under one session, sharing state.
a strict allowlist of binary-operation shapes — Frida exposes the full V8 JS API to scripts but the MCP wrappers only call the canonical, well-understood primitives (attach, spawn, enumerate, hook, RPC).
soft-skip behaviour — when the frida Python module or
the native libfrida are missing, every tool returns WARN
with an install hint and the plugin keeps working.
Tool | What it does |
| Health check — return frida version, native lib presence, USB device list |
| Spawn a new process under Frida (target: Android / iOS / native PID / remote endpoint) |
| Attach to a running process by host PID |
| Compile + load a Frida script (JavaScript) into a session |
| Call a method on a loaded script's exports (RPC) |
| List modules loaded into the session's process |
| List exports of a single module |
| Install an Interceptor hook on a named method |
| Register a Python-side callable as an RPC export the JS side can call |
| Tear down a session, unload scripts, detach |
Related MCP server: Frida MCP Server
Frida is a heavy install (the Python module pulls in frida +
frida-tools; the underlying libfrida is a native shared
library shipped via PyPI wheels). To install standalone:
pip install -e ./servers/re-fridaOn the target device (the phone or VM Frida is talking to),
the matching frida-server binary must be running. See
https://frida.re/docs/.
re-frida # stdio transport (default for MCP)
python -m re_frida # equivalentThe original Explore findings called for a Frida server; this
plugin-internal scaffolding lands it so the deep-dive agents can
pick it up. The Windows targets in the Live Fire stress test
still use re-winedbg as the primary dynamic tool; the Android
target future run is where re-frida becomes the workhorse.
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::
{
"status": "OK",
"session_id": "...",
"pid": N,
"device_id": "...",
"kind": "attach"
}
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| pid | Yes | ||
| device_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It includes the return structure but does not disclose potential failure modes, side effects, or permissions requirements. The tool appears simple, but more context on error behavior 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?
The description is concise, with a clear structure: a one-sentence summary, followed by parameter definitions in bullet style, and a return format block. No redundant or missing information. Every sentence serves a 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?
Given the tool's simplicity and lack of output schema, the description provides a complete enough picture: it explains parameters and return format. However, it omits details on when the tool might fail (e.g., invalid PID, missing permissions) which could be important for an agent. Still, it covers the essential context.
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 input schema has 0% coverage (only titles and types), so the description's parameter explanations add significant meaning. It clarifies 'session' as session id, 'pid' as host PID, and 'device_id' as optional with empty meaning first available. This goes beyond schema to provide practical semantics.
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 ('attach'), resource ('running process'), and method ('by host PID'). It distinguishes from siblings like 'start_session' which creates a new session, and 'script_load' which loads a script. The purpose is unambiguous.
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 does not provide explicit when-to-use or when-not-to-use guidance. It implies use when attaching to a process by PID, but no alternatives or exclusions are mentioned. The context is clear but lacks strategic decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return frida version + native lib presence + USB device list.
Soft-skip behaviour: when frida Python module or the
native libfrida is missing, returns status: WARN with
an install hint (pip install frida frida-tools). The
rest of the plugin continues to work — re-frida's tools just
return errors when called.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses soft-skip behavior and what happens when dependencies are missing (WARN, not crash). No annotations to contradict.
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 short paragraphs with front-loaded purpose and clear behavioral details. No wasted words.
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?
Fully describes tool purpose, return values, and edge cases. No gaps given zero parameters and no output schema.
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?
No parameters; schema coverage 100%. Baseline score for zero parameters is 4.
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 it returns frida version, native lib presence, and USB device list, with specific verb and resource. No ambiguity.
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?
Describes soft-skip behavior and when it returns WARN, but does not explicitly differentiate from siblings. However, its diagnostic purpose is clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tear down a session, unload scripts, detach from the process.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must convey behavioral traits. It mentions destructive actions ('tear down', 'unload', 'detach') but lacks details on side effects, reversibility, required permissions, or behavior if the session doesn't exist.
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 with no wasted words. However, it could be better structured by explicitly stating the action and its object, but it is not verbose.
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 destructive tool with one parameter and no output schema, the description omits important context such as the need for an active session, error handling, and what 'tear down' entails. It is not complete enough for an agent to use confidently.
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 description coverage is 0% and the description does not explain what the 'session' parameter should be (e.g., session ID or handle). The parameter's meaning is entirely unclear.
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 'tear down' and the resource 'session', and further specifies actions 'unload scripts, detach from the process'. This distinguishes it from siblings like start_session, which creates a session.
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?
No guidance on when to use this tool (e.g., after a session is active) or when not to use it. No mention of alternatives or prerequisites, such as the need for an existing session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List exports of a single module.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| module | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry all behavioral disclosures. It only states the action (list) without indicating whether it is safe, read-only, or has side effects. No authorization or rate limit info.
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 concise (one sentence) but may be too minimal. It could benefit from additional context without being verbose.
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?
No output schema is provided, and the description does not describe return values. The parameters are unexplained. While the tool is simple, the description leaves critical gaps for correct usage.
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 description coverage is 0%, and the description does not explain what 'session' or 'module' represent. The agent has no semantic context for these parameters beyond their names.
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 'List' and the resource 'exports of a single module', distinguishing it from sibling tools like enumerate_modules which lists modules. The scope is explicit.
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?
No guidance is provided on when to use this tool vs alternatives like enumerate_modules or rpc_export. There is no mention of prerequisites or prohibitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List modules loaded in the session's target process.
Returns base address, size, and on-disk path for each module.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses the read-only nature and return fields, but does not mention permissions, side effects, or limitations (e.g., whether modules are listed for all sessions or only live sessions). With zero annotations, the description only partially covers behavioral 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?
The description is two sentences, front-loaded with the action and return values. Every sentence adds value without unnecessary words.
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 no output schema, the description usefully explains return fields. However, it lacks details about the session parameter and potential errors or empty results. The tool is simple, so completeness is adequate but not thorough.
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 only parameter 'session' is required but not explained in the description (e.g., how to obtain it, accepted formats). Since schema description coverage is 0%, the description should compensate but does not. The agent may not know how to provide a valid session identifier.
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 specifies the verb 'List' and the resource 'modules loaded in the session's target process,' clearly distinguishing it from sibling tools like enumerate_exports. It also lists the return data (base address, size, path), ensuring the agent understands what the tool provides.
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?
No explicit guidance on when to use this tool vs alternatives (e.g., enumerate_exports). The description implies it's for listing all modules, but does not exclude other use cases or state prerequisites like an active session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a tracing hook on module:symbol.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| module | Yes | ||
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behavioral traits: captures arguments on-enter and return value on-leave, posts messages to Python side. Missing details on permissions, side effects, or hook removal.
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?
Three sentences: first states action, second explains behavior, third provides examples. Front-loaded, no redundant words, perfectly concise.
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?
Describes core function and gives usage examples, but lacks details on output/message format, hook lifecycle (persistence, removal), error handling, and session significance. Adequate but not comprehensive.
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?
With 0% schema description coverage, the description only indirectly explains 'module' and 'symbol' via the phrase 'on module:symbol'. The 'session' parameter is not explained at all, leaving ambiguity about its role.
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 explicitly states 'Install a tracing hook on module:symbol', clearly specifying the action and target resource. This distinguishes from sibling tools like attach_pid or enumerate_modules, which serve different purposes.
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 specific use cases (e.g., tracing bytecode dispatcher, MBA handler, anti-debug callback) giving clear context for when to use. However, lacks explicit 'do not use' guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a stub Python-side RPC export the script side can call.
The function is a reflective shim that returns None; the
analyst wires the real Python callable by calling
re_frida.runner.rpc_export(session, name, fn) from a
follow-up script. The MCP layer intentionally avoids taking
a Python callable as a JSON argument (which the MCP
protocol can't transport).
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the function returns None, is a reflective shim, and explains why it cannot accept a Python callable due to protocol limitations. This adds behavioral context beyond the absence of annotations.
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 brief with two sentences and a code example, efficiently conveying the core behavior. It is well-structured and front-loaded with the primary 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?
Given the tool's specialized nature and lack of output schema, the description covers the overall process but lacks detail on parameter semantics and return values (returns None). It provides adequate context for the intended use case but leaves gaps.
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?
With 0% schema description coverage, the description must compensate, but it only mentions 'session' and 'name' in passing without detailing their meaning, format, or constraints. For example, it does not specify what constitutes a valid session string or naming conventions.
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 that the tool registers a stub RPC export that the script side can call. It distinguishes itself from taking a Python callable directly, which aligns with its unique purpose among sibling tools. However, it does not explicitly differentiate from other registration-like tools.
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 explains that the tool is a reflective shim and implies usage via the follow-up wiring step. It does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives, leaving the agent to infer the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call method on a loaded script's exports.
Args:
session: session id
name: script name (from script_load)
method: the JS-side export to call. Scripts declare
exports via rpc.exports = { myFn(arg) { ... } }.
args: JSON-serialisable positional arguments
timeout_s: RPC timeout (default 10s)
Returns the return value, or the error string when the JS side threw.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| name | Yes | ||
| method | Yes | ||
| args | No | ||
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it calls a JS export, accepts JSON-serialisable args, defaults timeout to 10s, and returns the return value or error string. No contradictions.
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 concise (8 lines) and well-structured with an "Args:" bullet list. Every sentence adds value without repetition or fluff.
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 no output schema or annotations, the description covers all necessary aspects: parameter usage, return value, error handling, and prerequisite (script must be loaded via script_load). It is complete for the tool's purpose.
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?
Despite 0% schema description coverage, the description provides detailed meanings for all 5 parameters: session is session id, name is script name from script_load, method is JS-side export with example, args are JSON-serialisable positional args, timeout_s is RPC timeout with default 10s.
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 uses a specific verb "Call" and identifies the resource as "method on a loaded script's exports". It clearly distinguishes from sibling tools like script_load (loads script) and enumerate_exports (lists exports).
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 implies usage after script_load and explains the role of each parameter (session, name, method, args, timeout_s). It does not explicitly state when not to use it or name alternatives, 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.
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 Interceptor /
Java.perform / ObjC.classes APIs are
available inside the script.
Returns::
{"status": "OK", "session_id": "...", "script": "...", "scripts_loaded": [...]}
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| name | Yes | ||
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that Frida injects V8 and makes standard APIs available, and it specifies the return format. However, it does not mention potential errors, permissions, or side effects (e.g., loading multiple scripts). Overall, it provides good behavioral context.
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 well-structured with a summary line, bullet-point arguments, context, and return format. It is front-loaded and each sentence adds value. It could be slightly more concise, but the level of detail is appropriate.
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 tool with 3 required string parameters and no output schema, the description covers input, behavior, and output thoroughly. It assumes an active session, which is reasonable given sibling tools. Missing minor details like error handling, but overall complete.
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 description coverage is 0%, so the description must compensate. It explains each parameter: session as session id, name for lookup, and source with context about available JavaScript APIs. This adds significant meaning beyond the schema's minimal property names.
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's purpose: 'Compile + load a Frida script (JavaScript) into a session.' It uses a specific verb and resource, and the addition of 'into a session' distinguishes it from sibling tools like script_call (which calls a loaded script) and hook_method (which hooks a method). No ambiguity.
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 usage instructions via the argument list, but it does not explicitly state when to use this tool versus alternatives. For example, it does not mention that this is a prerequisite for script_call or when not to use it. The guidance is implied from context but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. "android-game").
target: package name (Android), bundle ID (iOS), or
absolute path to a native binary.
device_id: "usb", "local", "remote:<addr>",
or a specific device id. Empty string means the
first available device.
spawn_args: extra argv to pass to the target on spawn.
wait: when True (default), block until the spawned
process is unpaused.
Returns::
{
"status": "OK",
"session_id": "...",
"pid": N,
"device_id": "...",
"kind": "spawn"
}
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | ||
| target | Yes | ||
| device_id | No | ||
| spawn_args | No | ||
| wait | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: spawning, session creation, parameter effects (especially wait causing blocking), and return format. Could mention session lifecycle or cleanup, but sufficient.
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?
Well-structured with Args section and return example. Somewhat verbose but efficient; every sentence adds value. Could be slightly more concise without losing clarity.
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 all parameters and return format. For a spawn tool with 5 params and no output schema, it provides sufficient information for correct use. Lacks edge cases or error scenarios, but adequate.
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?
With 0% schema coverage, the description adds substantial meaning: explains session as user-chosen readable id, target as package/bundle/path, device_id formats, spawn_args as extra argv, wait as blocking behavior. Fully compensates for schema gaps.
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 spawns a target on a named device and opens a Frida session. It uses a specific verb ('Spawn') and resource, distinguishing it from siblings like attach_pid.
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?
No guidance on when to use this tool versus alternatives such as attach_pid. The description does not specify prerequisites or exclusions, making it hard for an agent to choose correctly.
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.
v0.1.0attach_pidcheck_fridaend_sessionenumerate_exportsenumerate_moduleshook_methodrpc_exportscript_callscript_loadstart_sessionEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Heretek-RE/re-frida'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
