Frida Agent MCP

by 1193776794

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some potential overlap between 'execute' and 'spawn_and_inject', as both inject scripts, with the latter being a convenience wrapper. The descriptions clarify the differences, so confusion is minimal.
Naming Consistency4/5
Tool names follow a consistent verb-based pattern (e.g., connect, detach, execute, get_messages), with minor deviations like 'logcat' (a noun) and 'spawn_and_inject' (compound verb). Overall, naming is readable and mostly uniform.
Tool Count5/5
With 10 tools, the count is well-suited for the server's purpose of Android app instrumentation with Frida. It covers essential operations like connection management, script injection, app control, and debugging without being overwhelming.
Completeness5/5
The tool set provides comprehensive coverage for the domain, including session management (connect, detach, reconnect), script injection (execute, spawn_and_inject), result retrieval (get_messages), app control (kill_app, launch_app, list_apps), and debugging (logcat). No obvious gaps are present.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'detaches' and 'unloads scripts', implying it's a cleanup/mutation operation, but doesn't specify critical details like whether this is reversible, what happens to session data, or if it requires specific permissions. The description is too vague for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('detach') and adds necessary context ('unload any injected scripts'). Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is minimally adequate. However, as a mutation tool with no annotations, it should provide more behavioral context (e.g., side effects, prerequisites) to be fully complete.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('detach', 'unload') and resources ('current session', 'injected scripts'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'reconnect' or 'kill_app', which might have overlapping cleanup functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'reconnect' or 'kill_app'. It doesn't mention prerequisites (e.g., must be in an active session) or exclusions (e.g., don't use if you need to maintain session state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action without mentioning side effects, success/failure conditions, permissions needed, or what happens if the app is already running. This leaves significant behavioral gaps for a mutation tool.
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?
The description is efficiently structured with a clear purpose statement followed by parameter documentation. Both sentences earn their place, though the 'Args:' formatting could be more integrated with the main description text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations but with an output schema, the description adequately covers the basic purpose and parameter. However, it lacks important behavioral context about what the launch operation entails and what the output might contain.
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?
With 0% schema description coverage and only one parameter, the description fully compensates by clearly explaining the 'package' parameter with a helpful example ('com.example.app'). It adds essential semantic context that the schema alone lacks.
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?
The description clearly states the specific action ('Launch') and target resource ('Android app by package name'), distinguishing it from siblings like 'kill_app' or 'list_apps'. It provides a complete verb+resource specification with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'spawn_and_inject' or 'execute', nor does it mention prerequisites or context requirements. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Force stop' which implies a destructive mutation, but doesn't disclose behavioral traits like required permissions (e.g., root access), side effects (e.g., app data loss), error conditions, or confirmation prompts. The description adds minimal context beyond the basic action.
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?
The description is appropriately sized with two sentences: a purpose statement and parameter explanation. It's front-loaded with the core action, though the parameter section could be slightly more integrated. Every sentence adds value, with no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 1 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral disclosure, it lacks details on safety, errors, or device state requirements, leaving gaps for an agent.
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?
With 0% schema description coverage, the description compensates by explaining the single parameter 'package' with a clear example ('com.example.app'), adding meaningful semantics beyond the schema's bare type. However, it doesn't detail format constraints (e.g., valid package patterns) or edge cases, keeping it from a perfect score.
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?
The description clearly states the specific action ('Force stop') and target resource ('an Android app by package name'), distinguishing it from siblings like 'launch_app' (which starts apps) and 'list_apps' (which enumerates them). The verb 'Force stop' precisely indicates termination rather than graceful shutdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to forcibly terminate an Android app, but provides no explicit guidance on when to use this versus alternatives (e.g., 'detach' or system-level commands) or any prerequisites (e.g., device connectivity). It lacks clear exclusions or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool returns 'application identifier, name, and PID', which adds some behavioral context, but lacks details on permissions needed, rate limits, or whether it's a read-only operation (though implied by 'List').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by return details. Every sentence adds value without waste, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, but has an output schema), the description is reasonably complete. It explains what the tool does and what it returns, though it could benefit from more behavioral context given the lack of annotations.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately omits parameter details, earning a high baseline score for not adding unnecessary information.
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?
The description clearly states the verb ('List') and resource ('running applications on the connected device'), specifying exactly what the tool does. It distinguishes itself from siblings like 'kill_app' and 'launch_app' by focusing on enumeration rather than management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. While it's implied this is for listing applications, there's no mention of prerequisites (e.g., requiring a connection via 'connect' first) or comparisons to similar tools like 'get_messages'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool fetches log output and can clear the buffer, which are key behavioral traits. However, it lacks details on permissions needed, rate limits, output format (though output schema exists), or side effects beyond clearing. This is adequate but minimal for a tool with mutation potential (clear parameter).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose and usage context, followed by a clear Args section. Every sentence earns its place—no fluff or repetition. It's appropriately sized for a tool with three parameters and an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is fairly complete. It covers purpose, usage hint, and parameter semantics. The output schema handles return values, so the description doesn't need to explain those. However, it lacks details on dependencies (e.g., device connection) and error cases, which could be important for debugging tools.
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 description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'filter' is a case-insensitive match on lines, 'lines' specifies the number of recent lines with a default, and 'clear' indicates buffer clearing. This goes beyond the schema's basic titles, providing context for all three parameters. Not a 5 because it doesn't detail filter syntax or clearing implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get Android logcat output' with a specific verb ('Get') and resource ('Android logcat output'). It distinguishes from siblings like 'get_messages' or 'execute' by focusing on system logs rather than app messages or code execution. However, it doesn't explicitly differentiate from all siblings (e.g., 'connect' or 'detach'), keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Useful for debugging crashes after script injection.' This suggests when to use it (post-injection debugging) but doesn't explicitly state when NOT to use it or name alternatives. No guidance on prerequisites like needing a connected device, which is a gap given siblings like 'connect' and 'reconnect'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions that messages are 'collected from the injected script's send() calls,' which adds some behavioral context about data source. However, it lacks details on permissions, rate limits, or what happens if no messages are available, leaving gaps for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a purpose statement, usage guideline, and parameter explanations in a bullet-like format. Every sentence adds value without redundancy, making it easy to parse and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers purpose, usage, and parameters, but lacks details on return values, error handling, or integration with siblings like 'spawn_and_inject'. For a tool with 3 parameters and complex context, more behavioral info would enhance completeness.
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 description coverage is 0%, so the description must compensate. It explains all three parameters: 'limit' for maximum messages, 'offset' for pagination, and 'save_to_file' for saving to JSON. This adds meaningful semantics beyond the schema's basic types and defaults, though it doesn't cover edge cases like file paths or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get messages collected from the injected script's send() calls.' It specifies the verb ('Get') and resource ('messages'), and provides context about their origin. However, it doesn't explicitly differentiate from sibling tools like 'logcat' or 'execute', which might also retrieve data, so it doesn't reach the highest score.
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?
The description includes a usage guideline: 'Call this after the user has triggered the target functionality.' This provides clear context on when to use the tool. However, it doesn't specify when not to use it or name alternatives among siblings, such as when to use 'logcat' instead, so it's not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the behavioral sequence (kill, relaunch, connect, inject) and mentions using send() for data return, which adds useful context. However, it lacks details on permissions, error handling, or side effects, leaving some behavioral aspects unclear.
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?
The description is well-structured with a purpose statement, usage guidelines, and parameter explanations in separate sections. It is appropriately sized with no redundant information, though the parameter details could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (combining multiple operations) and no annotations, the description covers purpose, usage, and parameters effectively. With an output schema present, it doesn't need to explain return values, making it reasonably complete for the context.
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 description coverage is 0%, so the description must compensate. It explains all three parameters: 'package' as the app package name with an example, 'script' as Frida JavaScript code with usage note, and 'script_file' as a path for large scripts. This adds significant meaning beyond the bare schema, though it could provide more on format or constraints.
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?
The description clearly states the specific action sequence: kill app, relaunch, connect, and inject script. It distinguishes from siblings by combining multiple operations (kill_app, launch_app, connect, execute) into one tool, making the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'when you need to hook early initialization (e.g. onCreate, static initializers).' It also mentions the equivalent sibling tools (kill_app, launch_app, connect, execute), providing clear alternatives and context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the technical behavior (adb port forwarding, connecting to zygisk-gadget) and the prerequisite nature, but doesn't mention potential failure modes, timeout behavior, or what happens if the device isn't available. It adequately describes the core action but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste: first states the action, second explains the mechanism, third provides usage guidance. Every sentence earns its place by adding essential information. The description is appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (connection setup), no annotations, 0 parameters, and presence of an output schema, the description is reasonably complete. It explains what the tool does, how it works, and when to use it. The output schema will handle return values, so the description doesn't need to explain them. Minor gap: doesn't mention what 'connected' state enables for subsequent operations.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter semantics, but it correctly implies no parameters are needed for this connection operation. Baseline for 0 parameters is 4.
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?
The description clearly states the specific action ('Connect to the Frida gadget on the device') and the mechanism ('Performs adb port forwarding (tcp:14725) and connects to the zygisk-gadget'). It distinguishes itself from siblings like 'detach', 'reconnect', or 'spawn_and_inject' by being the initial connection setup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Call this before any other operation'), providing clear prerequisite guidance. It implies alternatives by positioning itself as the initial step, though it doesn't name specific alternatives like 'reconnect' for re-establishing connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses key behavioral traits: it detaches the current session, re-establishes adb forwarding, and reconnects, which are useful details beyond just the name. However, it lacks information on permissions needed, error handling, or side effects (e.g., impact on other tools), leaving some gaps in transparency for a recovery operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by specific steps in a logical order. Every sentence earns its place by providing essential guidance without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, an output schema exists (which handles return values), and no annotations, the description is mostly complete. It explains the purpose, usage context, and post-reconnect steps. However, it could be more complete by mentioning potential errors or dependencies on other tools (e.g., requires 'connect' to have been called first), slightly reducing completeness for a recovery tool.
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?
The input schema has 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description does not need to add parameter details, and it correctly implies no parameters are needed by not mentioning any. This meets the baseline of 4 for zero parameters, as it doesn't contradict or add unnecessary information.
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?
The description clearly states the specific action ('Reconnect to the gadget after an app crash') and the resources involved (gadget, app). It distinguishes from siblings like 'connect' (initial connection) and 'detach' (disconnection only) by specifying it's for recovery after a crash, not initial setup or simple detachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('after an app crash') and provides clear alternatives in the workflow ('After reconnect, restart the target app and call execute() again'), distinguishing it from tools like 'launch_app' or 'execute' that handle different stages. It also implies when not to use it (e.g., for initial connection, use 'connect').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the script is wrapped with try-catch for safety, the tool returns immediately after injection (asynchronous behavior), and results must be retrieved via get_messages(). However, it doesn't mention potential side effects like application instability or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement upfront, followed by behavioral details, and then parameter explanations. Every sentence adds value: the first states what it does, the second explains safety wrapping, the third clarifies async behavior and result retrieval, and the parameter section provides practical guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (code injection into running applications) and lack of annotations, the description does well by explaining the async nature, safety mechanism, and parameter usage. However, it doesn't mention potential failure modes or security implications. The presence of an output schema means return values don't need explanation, but more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 fully. It provides clear semantic meaning for both parameters: 'script' is Frida JavaScript code with guidance to 'Use send() to return data', and 'script_file' is a path to a .js file for large scripts. The description adds essential context beyond the bare schema.
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?
The description clearly states the specific action ('Inject a Frida JavaScript script') and target ('into the frontmost application'), distinguishing it from siblings like 'spawn_and_inject' (which likely spawns a new process) or 'connect' (which establishes connection). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Returns immediately after injection - use get_messages() to retrieve results after the user has triggered the target functionality') and provides a clear alternative for large scripts ('Use this for large scripts instead of script parameter'). It also distinguishes from siblings by specifying it targets the 'frontmost application'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![frida-mcp MCP server](https://glama.ai/mcp/servers/1193776794/frida-mcp/badges/card.svg)](https://glama.ai/mcp/servers/1193776794/frida-mcp)

Score Badge

Copy to your README.md:

[![frida-mcp MCP server](https://glama.ai/mcp/servers/1193776794/frida-mcp/badges/score.svg)](https://glama.ai/mcp/servers/1193776794/frida-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/1193776794/frida-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server