Loading ToolBench
Yet Another Frida MCP Server - Full-featured MCP server for Frida dynamic instrumentation
The server has solid naming conventions (verb_noun pattern) and reasonable descriptions for most tools. However, there are significant gaps in schema completeness, parameter descriptions, and error handling guidance. Output schemas are not documented. Tool descriptions lack WHEN/WHY context that would help LLMs select the right tool. Parameter descriptions exist but are sparse and lack validation constraints (enums, ranges, formats). Error handling is minimal, no recovery guidance or actionable error messages visible in the provided code. The server uses fastmcp with explicit schema registration, which is good, but the schemas themselves are underdocumented for downstream LLM reasoning.
Disable Android USAP pool and detect root-hiding modules that interfere with Frida spawn. Call this when frida_spawn times out or returns "unable to find executable". The tool: 1. Disables USAP-related system properties (requires root/su) 2. Kills lingering usap32/usap64 processes 3. Detects active root-hiding modules (Shamiko, ZygiskSU, etc.) If spawn still fails after this fix, check the returned ``root_hiders`` list — those modules may need to be disabled manually in their respective manager apps.
Get details about the frontmost application.
List installed applications on a device (frida-ls equivalent). Returns identifier, name, and PID (if running).
List only currently running applications.
Download and push frida-server to the device. If *version* is omitted, uses the locally installed Frida client version to ensure client/server compatibility.
Start frida-server on the device (must already be pushed).
Output schemas are not documented. Tool descriptions state what they return (e.g., 'identifier, name, and PID') but there is no formal schema definition visible for downstream LLM reasoning about return fields, types, or structure. LLMs cannot plan multi-step chains or extract specific fields from responses without knowing the response schema.
Parameter descriptions lack constraint documentation. 'scope' parameter accepts 'minimal', 'metadata', or 'full', but the description does not formally declare these as enum values. LLMs may hallucinate other values. 'device_id' and 'device' descriptions say 'Uses default if omitted' but do not specify what the default is or how to discover available devices.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Check if frida-server is running on the device and whether its version matches the local Frida client.
Stop frida-server on the device.
Tool descriptions lack WHEN/WHY guidance. Descriptions state WHAT the tool does but not when an LLM should call it vs. a similar tool. E.g., 'frida_ls_apps' vs 'frida_ls_apps_running', no guidance on choosing between them. 'frida_server_status' vs 'frida_server_install', when should the LLM check status before installing? This forces the LLM to reason about sequencing without explicit direction.
No error handling guidance or recovery instructions visible. Code shows `try/except` blocks but the error messages returned to the LLM are not documented. When 'frida_server_install' fails to download a binary, what error does the LLM see? How should it recover? The descriptions do not explain dependencies (e.g., 'frida_server_install requires ADB to be available') or what to do if they are unmet.
'frida_fix_usap' description is overly long (>300 chars) and mixes explanation with procedural steps. It explains what USAP is, what root-hiding modules are, and what to do if the tool fails, all in one dense block. This violates the 10-1024 char guideline (pragmatically 150-300 optimal for LLM parsing). Break into separate statements: purpose, preconditions, expected return value, error recovery.
Parameter 'identifiers' in frida_ls_apps lacks clarity. The description says 'Optional list of bundle identifiers to filter by' but does not explain what 'bundle identifier' means, what format it takes (e.g., 'com.example.app'), or how to discover valid identifiers without calling another tool first.
'frida_server_install' description does not explain the version parameter behavior clearly. It says 'If omitted, uses local Frida client version' but does not state whether this is always safe, when version mismatches occur, or how to check the current version without calling install.
Tool names 'frida_server_*' are well-chosen but do not convey risk level. 'frida_server_install', 'frida_server_start', and 'frida_server_stop' are WRITE operations that modify device state, yet the naming does not signal this (e.g., 'update_', 'modify_', or a write-hint annotation would help). LLMs cannot distinguish safe (READ) vs. destructive (WRITE) tools by name alone.