frida-mcp

by Gindhar2112

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
Disambiguation5/5
Each tool has a distinct purpose: lifecycle management (connect, detach, reconnect), script injection and retrieval (execute, get_messages), app control (kill_app, launch_app, list_apps), logging (logcat), and a composite workflow (spawn_and_inject). No overlapping functionality.
Naming Consistency5/5
All tool names use lowercase snake_case with a verb_noun pattern (e.g., kill_app, launch_app, get_messages). The composite tool spawn_and_inject deviates slightly but remains intuitive and consistent with the overall style.
Tool Count5/5
10 tools is well-scoped for a Frida interaction server. It covers connection management, app lifecycle, script injection, message retrieval, and debugging without unnecessary clutter.
Completeness4/5
Core workflows are covered: connect/disconnect, app start/stop/list, script injection with message retrieval, and logcat. Missing advanced features like listing active hooks or managing multiple scripts, but the set is complete for typical Frida use cases.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
No annotations are present, so the description carries the full burden for behavioral disclosure. It notes that save_to_file=True will save to a JSON file and return the path, which is a side effect. However, it does not disclose whether retrieving messages is idempotent, whether the buffer resets after reading, or any rate limits. Critical behavioral traits like these are missing, making it insufficient for safe agent reasoning.
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 concise with three short sentences plus parameter list. The purpose is front-loaded, and the usage timing hint follows immediately. There is no extraneous information. A small improvement would be to integrate the parameter descriptions more seamlessly, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage, no annotations, and no output schema, the description has a heavy burden that it only partially meets. It explains parameters and usage timing but omits the return format (e.g., what does the tool return when save_to_file is False? Are messages in a particular structure?). Also missing is behavior on repeated calls and possible errors. The description is incomplete for making informed decisions.
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% description coverage, so the description must explain each parameter. It does so: limit as maximum messages (default 50), offset for pagination, save_to_file for saving to JSON. These explanations add meaning beyond the schema's type and default values. The only gap is no explanation of offset's default value (0) or interaction with limit.
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 that the tool retrieves messages from the injected script's send() calls. The verb 'get' and resource 'messages' are specific. The context of injection and send() adds clarity, though it could be more explicit about what messages represent. Compared to siblings like launch_app or execute, this tool's purpose is distinct, but no explicit differentiation is given.
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 one key usage guideline: 'Call this after the user has triggered the target functionality.' This gives a precondition for use. However, no guidance on when not to use it or alternatives is provided. Given the sibling tools cover different actions (e.g., connect, execute), the lack of exclusion is acceptable, but the guideline is minimal.
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 provided, so description should disclose side effects. Only says 'force stop' without mentioning process termination, data loss, permissions, or error cases.
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?
Two sentences, front-loaded with purpose. No redundant words.
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?
Minimal but adequate for a simple destructive tool. Output schema exists, so return values are covered. Lacks edge-case details (e.g., app not installed, root required).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, description only gives an example format for package but no additional semantics like validation, format constraints, or behavior if invalid.
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?
Description clearly states verb (force stop), resource (Android app), and method (by package name). It distinguishes from sibling tools like launch_app (start) and list_apps (list).
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 on when to use this tool vs alternatives (e.g., launch_app, detach). No prerequisites or exclusions mentioned.
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, the description carries the full burden. It states only the action (launch) without disclosing what happens if the app is already running, potential side effects, or required permissions. Minimal behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and a single parameter definition. It is front-loaded, wastes no words, and covers the core information efficiently.
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 simplicity (one required parameter, no annotations, output schema exists), the description is adequate. However, it could mention whether the launch blocks or returns immediately, or any error conditions. It covers the basics but misses useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by providing the example 'com.example.app' and explaining the parameter as 'The app package name.' This adds basic meaning but lacks details like format or constraints (e.g., length, valid characters).
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 tool's purpose: 'Launch an Android app by package name.' The verb 'launch' and resource 'Android app' are specific, and the method (by package name) is evident. This distinguishes it from sibling tools like kill_app (kill) or list_apps (list).
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 like 'execute' (which runs commands) or other siblings. There is no mention of prerequisites, restrictions, or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses unloading of injected scripts, but lacks details on side effects like whether it kills processes or just disconnects. Without annotations, the description carries the full burden but is somewhat limited.
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?
Single, concise sentence with no unnecessary words. Well front-loaded.
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?
For a simple zero-parameter tool, the description is adequate. It could mention when detach is needed (e.g., before reconnecting), but overall 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?
No parameters exist, so description need not add parameter info. Schema coverage is 100%, baseline 4 applies.
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 action (detach from session) and the specific behavior (unload injected scripts). It distinguishes from siblings like 'connect' and 'reconnect'.
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 ending a session or cleaning up, but no explicit guidance on when to use or not use versus alternatives.
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 must fully disclose behavior. It states the tool lists apps and returns specific data, but does not mention side effects, permission requirements, or that it is read-only.
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?
Two sentences with no extraneous information. Front-loads the action and efficiently details the return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description sufficiently explains the tool's behavior. No gaps identified.
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?
There are zero parameters, and the schema coverage is 100%. The description adds value by specifying what the output contains (identifier, name, PID), going beyond the 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 it lists running applications on a connected device and specifies the return fields (identifier, name, PID). This distinguishes it from sibling tools like launch_app or kill_app.
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 for viewing running applications, but provides no explicit guidance on when to use it versus alternatives or any prerequisites or limitations.
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 exist, so the description bears full burden. It describes the clear parameter as destructive to buffer and filter behavior (case-insensitive). However, it lacks disclosure of potential side effects like buffer clearing without fetching or system impact, so it's partial.
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 concise: a one-line purpose, a sentence of usage context, and a parameter list. Every sentence adds value with no redundancy.
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?
With an output schema present, return value explanation is unnecessary. The description covers the tool's purpose, parameters, and a key use case. It is complete for debugging tasks, though it could mention that logcat is a system buffer.
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 coverage is 0%, but the description adds meaning: explains filter (case-insensitive), lines (number of recent lines, default 100), and clear (buffer clearing). This goes beyond the schema's type/default info.
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 states 'Get Android logcat output' which is a clear verb+resource. It also provides context 'debugging crashes after script injection', distinguishing it from other sibling tools that are not logging-related.
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 explicitly says 'Useful for debugging crashes after script injection', indicating when to use. While no alternatives or when-not are given, the context is clear and there is no other logging tool among siblings, so it's adequate.
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 transparently outlines the sequence: detach current session, re-establish adb forwarding, and reconnect. It also clarifies what the tool does not do (e.g., restart the app or call execute). This is sufficient for a recovery 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 three sentences, each earning its place: purpose, procedure, post-usage instructions. No wasted words, front-loaded with key information.
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 simplicity, the description is fairly complete. It explains when to use, what it does, and what to do after. However, it omits prerequisites (e.g., adb availability) and error conditions. The existence of an output schema offsets the need to describe return values.
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 zero parameters, and the schema description coverage is 100% (no parameters to describe). Per guidelines, baseline is 4. The description does not need to add parameter meaning beyond the empty 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 tool's purpose: reconnect to the gadget after an app crash. It specifies the verb (reconnect) and resource (gadget), and distinguishes from siblings like 'connect' and 'detach' by contextualizing the usage scenario (post-crash) and outlining the steps performed.
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 provides explicit context ('after an app crash') and post-usage instructions ('restart the target app and call execute() again'). However, it lacks explicit guidance on when not to use this tool or comparison to alternatives, which would strengthen this dimension.
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?
No annotations provided, so description carries full burden. It discloses the underlying network action (adb port forwarding on tcp:14725) and target (zygisk-gadget). Lacks mention of error handling or side effects, but for a connection tool this is acceptable.
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?
Two sentences, no wasted words. Front-loaded with purpose and key details. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, presence of output schema (so return info covered), and simple task, the description covers all needed context: what it does, how it does it (port forwarding), and when to call it.
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?
No parameters defined; baseline score of 4 applies per guidelines. The description does not need to add parameter information, and schema coverage is 100% (trivially).
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?
Description clearly states verb 'Connect' and target 'Frida gadget' with specific actions (adb port forwarding, zygisk-gadget). Distinguishes itself from sibling tools like 'detach' or 'reconnect' by being the initial connection step.
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?
Explicitly says 'Call this before any other operation', providing clear ordering context. Does not discuss when not to use or alternative tools, but the directive is strong and sufficient for a setup tool.
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?
The description reveals key behaviors: automatic try-catch wrapping, immediate return, and result retrieval via get_messages(). With no annotations, this adds necessary transparency, though it omits potential side effects like app crashes.
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 concise, with a clear structure: purpose, safety note, behavior, parameter details. Every sentence adds value.
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?
The description covers parameters and post-injection workflow. It lacks prerequisites like Frida installation or running app, but the output schema likely handles return info. Minor gap.
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?
Both parameters are described with purpose and usage tips: script for code with send(), script_file for large .js files. This compensates for the 0% schema description coverage.
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 tool injects a Frida JavaScript script into the frontmost application, differentiating it from siblings like connect or detach that perform other actions.
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 instructs to use get_messages() to retrieve results after injection, providing workflow guidance. It could explicitly state when not to use this tool, but the context is sufficient.
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, the description carries full transparency burden. It clearly discloses the destructive behavior ('Kill app'), the sequence of actions, and the injection point ('at startup'). It could improve by mentioning potential failure modes or prerequisites, but it effectively communicates the main behavioral traits.
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 concise and well-structured: three sentences plus a bulleted argument list. It front-loads the main purpose, then provides usage guidance and argument details without extraneous information. Every sentence adds value.
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?
For a composite tool with an output schema, the description explains what it does, when to use it, and the arguments. It is complete enough for typical use cases, but could mention prerequisites (e.g., device connected) or note that the output schema describes the result. Overall, it's quite comprehensive.
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 coverage is 0%, so the description must fully compensate. It provides clear, actionable descriptions for all three parameters: 'package' is the app package name, 'script' is Frida JS code with guidance on using send(), and 'script_file' is a path for large scripts. This adds significant meaning 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 tool's purpose: 'Kill app, relaunch, connect, and inject script in one step.' It uses a specific verb and resource (a multi-step process for app injection) and implicitly distinguishes it from sibling tools by noting it's equivalent to chaining kill_app, launch_app, connect, and execute.
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 explicitly states when to use the tool: 'Use this when you need to hook early initialization (e.g. onCreate, static initializers).' It also implies when not to use it by labeling it as a composite of individual tools, suggesting those are alternatives for different needs. However, it could be more explicit about exclusion cases.
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/Gindhar2112/frida-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Gindhar2112/frida-mcp)

Score Badge

Copy to your README.md:

[![frida-mcp MCP server](https://glama.ai/mcp/servers/Gindhar2112/frida-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Gindhar2112/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/Gindhar2112/frida-mcp'

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