Four tools with complete input schemas and descriptions, but descriptions are minimal (10-60 chars, well below the 194-char baseline). All tools are READ_ONLY and lack error handling guidance. No output schemas documented. Parameter descriptions are present but terse. Tool names follow verb_noun pattern (miasm_*) but lack clarity on when to use each variant. No tool annotations (readOnlyHint, etc.) despite all being read-only. Missing guidance on prerequisites, expected return structures, and failure modes.

• Expand tool descriptions to 100-200 chars. Example: 'miasm_disassemble: Disassemble x86/ARM/MIPS machine code at a virtual address in a PE/ELF binary. Use this to inspect raw instructions; use miasm_lift_ir to analyze control flow and data dependencies.' This clarifies when to pick each tool.
• Document output schemas for each tool. Specify whether results are JSON objects, arrays of instructions, or strings. Include sample fields (e.g., 'Returns: {instructions: [{address, mnemonic, operands}], total_bytes_read}').
• Add error handling guidance: 'If PE file not found, verify the path is absolute and readable. If address is out of bounds, check the binary's section layout with a PE parser first. If architecture detection fails, pass arch explicitly (x86, x86_64, ARM).'
• Add readOnlyHint: true to all four tools in the tool definition to signal safety to LLMs and enable read-only agent configurations.
• Specify valid values for 'arch' parameter as an enum or constrained string: 'Architecture (x86, x86_64, ARM, ARM64, MIPS, MIPS64). Leave empty to auto-detect from PE header.' Add min/max for address and size (e.g., 'size: 1-65536 bytes').