Two tools with minimal schema documentation and generic descriptions. decompile_function has a single string parameter with basic description; list_functions has empty input schema. Neither tool documents output structure, error handling, or recovery guidance. Descriptions lack context on when to use each tool or what they return. No parameter validation rules, no error classification, no idempotent hints. Tool names follow verb_noun pattern (positive), but definitions fall well short of production baseline (194 char avg description, 100% param documentation in A+ tools).

• Add output schema documentation for both tools. decompile_function should return {code: string, function_name: string, status: 'success'|'error'}. list_functions should return {functions: [{name: string, class: string}], total: number}.
• Expand decompile_function description to ~150 chars: 'Decompile a single IL2CPP function to C code. Use after list_functions to get available names. Requires function name in ClassName$$MethodName format (e.g., CoinManager$$AddCoins). Returns decompiled C code or error if function not found.'
• Expand list_functions description to ~120 chars: 'List all functions in the loaded binary, grouped by IL2CPP class. Call this first to discover available functions before decompiling. Returns function names in ClassName$$MethodName format, one per line.'
• Add parameter validation: decompile_function 'name' should document format as regex pattern or enum-like constraint. Add error handling: 'If function not found, call list_functions to verify the name format and available functions.'
• Add tool annotations (readOnlyHint: true for both tools) to signal to agents that these are safe, non-destructive operations that can be retried.