Frida MCP Server - Minimal Android Hook Service using FastMCP
frida-mcp exhibits critical deficiencies across naming, descriptions, parameter documentation, and schema completeness. Of 3 tools, all suffer from inadequate descriptions and missing parameter-level validation documentation. Tool names lack clarity about intent (config_set is vague; config_save and config_init are domain-specific but not self-documenting for LLMs unfamiliar with Frida). Parameters lack type constraints, enums, ranges, and many lack individual descriptions. No output schemas are documented. Error handling is absent from the visible code. The server provides no guidance to LLMs on parameter relationships (e.g., 'os' must be set before platform-specific features, per the description, but no enum constraint or validation logic visible). The codebase shows mature Frida server management logic (AndroidServerManager, port forwarding, device checks) but no corresponding LLM-ready interface design.
Initialize project configuration. Run this at the start of each project.
Persist the current in-memory configuration to the project config file.
Update the current in-memory Frida configuration. Args: server_path: Path to frida-server binary server_name: Name of frida-server executable server_port: Port number for frida-server communication device_id: Default device identifier for connections adb_path: Path to ADB executable (Android only) os: Target operating system ('Android' or 'Windows') save_to: Persistence option - 'global' or 'project'
No enum constraints on 'os' parameter (accepts free-form string instead of explicit 'Android'|'Windows'). LLMs may hallucinate invalid OS values.
No enum constraints on 'save_to' parameter (accepts free-form string instead of 'global'|'project'). LLMs may pass invalid persistence modes.
No parameter-level descriptions for 'server_port' (integer type visible but no range constraint or format guidance). LLMs may pass invalid port numbers (0, 70000, negative).
No output schemas documented for any tool. LLMs cannot predict what fields are returned or plan downstream operations (e.g., what does config_set return on success? A status object? The updated config?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Tool descriptions lack actionable error guidance. No mention of what happens if file write fails, device is unreachable, or invalid parameters are passed.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. LLMs do not know which tools modify state (all three do) or whether they are safe to retry.
Parameter relationships undocumented. 'os' must be set before platform-specific features (per description), but no validation rule or dependency guidance visible. LLMs cannot infer the correct call order.
Generic tool names ('config_set', 'config_save') provide minimal intent signal. LLMs may conflate them with system configuration, environment setup, or other unrelated domains.