Provides tools for dynamic analysis of Android applications, enabling AI agents to list installed apps, manage application lifecycles, monitor system logs via logcat, and inject Frida scripts for real-time instrumentation.
Integrates with Magisk-rooted devices and the zygisk-gadget module to facilitate deep process instrumentation and automated reverse engineering on Android.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Frida Agent MCP trace the Cipher.doFinal method in com.taobao.taobao to see the encryption parameters"
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.
AI 驱动的 Android 动态分析工具。通过 MCP (Model Context Protocol) 让 AI 直接操控 Frida，实现自动化逆向分析。
AI (Claude) → MCP Server → Frida CLI → zygisk-gadget (手机) → 结果返回Python >= 3.10
Android 手机已 root，安装 Magisk
安装 zygisk-gadget Magisk 模块（固定端口 14725）
ADB 已连接手机
Related MCP server: ya-frida-mcp
pip install .安装后运行一键配置（注册 MCP + 安装 Skills）：
frida-mcp-setup或手动配置，在 ~/.claude.json 中添加：
{
"mcpServers": {
"frida-agent": {
"command": "frida-mcp"
}
}
}工具 | 说明 |
| 建立 ADB 端口转发，连接 zygisk-gadget |
| 列出设备上的第三方应用 |
| 注入 Frida JS 脚本到前台应用（支持 |
| 杀死 → 重启 → 注入，一步完成（适用于需要启动时 hook 的场景） |
| 获取注入脚本的输出（支持分页、自动文件回退） |
| 查看 Android 日志，排查崩溃原因 |
| 启动指定应用 |
| 强制停止指定应用 |
| 重新建立连接（崩溃后恢复） |
| 断开当前注入会话 |
安装后可在 Claude Code 中使用：
/reverse-analyze — 逆向分析与动态 Hook，结合 IDA 静态分析 + Frida 动态验证
/trace-vm — VM 保护函数分析，指导人工 trace 并由 AI 分析结果
用户: hook 淘宝的 Cipher.doFinal 看看加密参数
AI 自动执行:
1. connect() — 建立连接
2. spawn_and_inject( — 启动并注入
"com.taobao.taobao",
"Java.perform(function() { ... })"
)
3. 提示用户触发操作 — "请点击登录按钮"
4. get_messages() — 获取 hook 结果
5. 分析并展示加密参数和返回值用户: /reverse-analyze 分析 libsgmain.so 中 0x1234 处的函数
AI 自动执行:
1. IDA MCP 反编译目标函数，分析参数和返回值类型
2. 生成 Frida Hook 脚本
3. spawn_and_inject 注入
4. 交叉验证静态分析和动态结果本工具使用 Frida CLI 而非 frida-python API，通过 frida -H 127.0.0.1:14725 -F -l script.js -o output.txt 注入脚本：
脚本中的 send() 调用自动转换为 console.log(JSON.stringify())
所有脚本自动包裹 try-catch 防止注入崩溃
输出通过 -o 标志写入文件，get_messages 时停止 frida 进程以刷新文件
src/frida_mcp/
├── server.py # MCP Server 入口，10 个工具注册
├── connection.py # Frida CLI 连接管理，进程生命周期
├── executor.py # 脚本预处理（send 转换、try-catch 包裹）
├── messages.py # 消息分页、大数据自动文件回退
├── logcat.py # Android logcat 封装
├── setup.py # 一键安装配置
└── skills/ # Claude Code 技能模板MIT
Connect to the Frida gadget on the device. Performs adb port forwarding (tcp:14725) and connects to the zygisk-gadget. Call this before any other operation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Detach from the current session and unload any injected scripts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Inject a Frida JavaScript script into the frontmost application. The script is automatically wrapped with try-catch for safety. Returns immediately after injection - use get_messages() to retrieve results after the user has triggered the target functionality.
Args: script: Frida JavaScript code to inject. Use send() to return data. script_file: Path to a .js file to inject. Use this for large scripts instead of script parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| script | No | ||
| script_file | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get messages collected from the injected script's send() calls. Call this after the user has triggered the target functionality.
Args: limit: Maximum number of messages to return (default 50). offset: Skip first N messages for pagination. save_to_file: If True, save all messages to a JSON file and return the path.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| save_to_file | No |
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.
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.
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.
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.
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.
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.
Force stop an Android app by package name.
Args: package: The app package name (e.g. com.example.app).
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Launch an Android app by package name.
Args: package: The app package name (e.g. com.example.app).
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List running applications on the connected device. Returns application identifier, name, and PID.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get Android logcat output. Useful for debugging crashes after script injection.
Args: filter: Optional filter string (case-insensitive match on each line). lines: Number of recent lines to fetch (default 100). clear: If True, clear logcat buffer before fetching.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | ||
| lines | No | ||
| clear | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Reconnect to the gadget after an app crash. Detaches current session, re-establishes adb forwarding, and reconnects. After reconnect, restart the target app and call execute() again.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Kill app, relaunch, connect, and inject script in one step. Use this when you need to hook early initialization (e.g. onCreate, static initializers). Equivalent to: kill_app -> launch_app -> connect -> execute.
Args: package: The app package name (e.g. com.taobao.taobao). script: Frida JavaScript code to inject at startup. Use send() to return data. script_file: Path to a .js file to inject. Use this for large scripts.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| script | No | ||
| script_file | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0connectdetachexecuteget_messageskill_applaunch_applist_appslogcatreconnectspawn_and_injectScored across 10 tools
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.
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.
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.
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.
MCP server for static security analysis of Android source code
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Remote MCP for Android CLI agent build gate, structured receipts, audit logs, and reviewer-ready evi
Melaya is a remote MCP server. It gives an assistant hands on your own Android phone and browser: it reads the screen through the accessibility tree, then taps, types and navigates inside the apps and sites you allow-list, with no per-app API. It also builds, schedules and runs agent pipelines across 6k+ connected tools. OAuth 2.1, nothing to install.
