Descriptions universally terse and non-actionable. 40 of 44 tools have descriptions under 30 characters ('List all devices', 'Disconnect', 'List processes'). LLMs cannot determine when/why to select tools or understand differences between similar tools (list_fields vs list_fields_with_parents, get_field_value vs get_field_offset). Rubric baseline: 194 chars avg, p10=34, p90=392.

Missing parameter descriptions across nearly all tools. Parameters like 'filter', 'mode', 'target', 'remote_host', 'imageOrName', 'classNameOrPtr', 'methodPtr', 'offset', 'size', 'transformPtr', 'instancePtr' have descriptions, but many optional parameters lack guidance on when to use them. No tool explains dependencies between parameters (e.g., how device_type, mode, target, and remote_host interact in frida_connect). Rubric baseline: 94% of A+ tools have param descriptions; 100% of A+ tool params have descriptions.

No input validation constraints. Parameters that should be enums (device_type: usb|remote|local, mode: spawn|attach_front|attach_name|attach_pid, sort: true|false) are typed as strings with only description text. No range constraints on numeric params (instructionCount, maxCount, offset, size, limit). LLMs cannot validate input and will pass invalid values.

No output schemas documented. None of the 44 tools document what they return, no field names, types, or structure. LLMs cannot plan downstream tool calls or extract chaining IDs (e.g., if frida_connect returns a session_id, downstream tools need to accept it). This blocks tool composition.

No error handling or recovery guidance. Tool descriptions do not explain error conditions, when/how to retry, or what to do if a tool fails. No distinction between retryable errors (connection timeout), user-fixable errors (invalid class name), and fatal errors (device disconnected). Pattern requires: 'User not found. Try search_users() with a partial name.'

Destructive operations lack confirmation patterns. il2cpp_exec_js, il2cpp_set_field_value, unity_send_message, memory_write, and all memory_alloc tools can modify process state or memory irreversibly. No description warns of side effects or suggests dry-run capability. Agents need explicit warnings.

Related tools lack distinction. il2cpp_list_fields and il2cpp_list_fields_with_parents, il2cpp_get_field_value and il2cpp_get_field_offset, unity_get_gameobject and unity_get_transform all perform similar operations but descriptions do not explain when to pick one over the other. LLMs will guess and waste calls.

No guidance on tool sequencing. A multi-step workflow like 'find a class → list methods → show assembly' is not documented. Descriptions do not hint at dependencies or prerequisites (e.g., 'Call il2cpp_list_classes first to discover image names'). Agents waste rounds rediscovering structure.