Single tool 'forkfuzz_scan' has a basic description (97 chars) but critically lacks parameter descriptions. The input schema defines 'target' as a string with a description ('Target path or contract specification to scan'), which is present but minimal. No output schema is documented. The tool description is generic and does not explain when to use it, what it returns, or prerequisites. No error handling guidance. The implementation is a simple wrapper around scan(target) returning JSON, but the MCP interface does not expose structured output schema or error recovery patterns.

• Add a detailed output schema documenting the JSON structure: e.g., {findings: [{id, sev, where}], score: number, tool: string}. Include field descriptions so LLMs know what each field means.
• Expand tool description to 150-250 chars: 'Scans a contract specification or source directory for invariant violations using mainnet-fork fuzzing. Returns a list of findings with severity levels (high/medium/low) and file locations. Use this to identify protocol risks before deployment.'
• Add format and validation rules to 'target' parameter: 'Path to a JSON contract spec file, Solidity source directory, or contract address. Must be readable and valid JSON or source code.'
• Implement error handling that returns actionable messages: 'Target not found at {path}. Ensure the path is absolute or relative to the working directory.' or 'Invalid JSON spec: {error_detail}. Check syntax and required fields.'
• Consider renaming to 'scan_contract_invariants' or 'fuzz_contract_mainnet_fork' to make the action and domain explicit.