Raze has 10 well-named tools with explicit schemas and descriptions. All tools follow verb_noun naming (raze_inspect, raze_attack, raze_analyze). Descriptions are present and contextual (avg ~120 chars), explaining WHAT and WHEN. However, parameter descriptions are minimal, most lack detail on format, constraints, or dependencies. The 'attackPlan' object parameter appears in 4 tools but is never documented (no schema visibility for its internal structure). Output schemas are not documented in the tool definitions. Error handling is absent, no recovery guidance, categorization, or actionable messages. Security: tools accept projectRoot as string with no path validation, risking directory traversal. No permission gates on destructive tools (raze_attack, raze_generate_proof_scaffold, raze_write_report). Overall: solid naming and basic structure, but parameter rigor and error handling lag production standards.

• Document the attackPlan schema explicitly. Show LLMs the required fields (e.g., vulnerability type, target function, exploit steps) so they can construct valid plans. Use a Zod schema or JSON Schema example in the tool description.
• Add output schema documentation to every tool. For raze_inspect_project, document: returns {contracts: [{name, path, dependencies, riskSignals}], dependencyGraph, summary}. For raze_analyze_contract, document: returns {findings: [{type, severity, description, location}], recommendations}.
• Enhance parameter descriptions with format and constraint details. E.g., projectRoot: 'Absolute or relative path to Foundry project root (must contain foundry.toml)'. contractSelector: 'Contract name (e.g., MyToken) or file path (e.g., src/MyToken.sol)'. goal: 'One-sentence description of the fuzz test objective (max 200 chars)'.
• Implement error categorization and recovery guidance. Return {error: 'contract_not_found', message: 'Contract MyToken not found in project. Available: [Token, Vault, Router]', retryable: false, nextStep: 'Try a different contract name or run raze_inspect_project to list all contracts'}.
• Add a dry-run parameter to destructive tools (raze_attack, raze_write_report) and implement permission checks. E.g., raze_attack with dry_run=true returns 'Would execute 3 attack plans' without side effects. Gate write operations behind a 'security:write' permission scope.