Single tool 'storagelens_scan' has a basic description (89 chars) and minimal input schema. The tool name uses verb_noun pattern correctly ('scan' action), but the description lacks clarity on WHEN to use it, WHAT it returns structurally, and prerequisites. Input schema defines only 'target' as string with a brief description, no type validation, enums, format constraints, or examples. No output schema documented. The tool appears to perform read-only file scanning for code patterns, but the description conflates storage layout analysis (contract proxy upgrades) with simple text pattern matching (TODO/FIXME/XXX comments visible in JavaScript/Go/Rust ports), creating confusion about actual capability. No error handling guidance, no pagination, no structured output specification.

• Clarify the actual capability: does this tool scan contract storage layouts for proxy upgrade collisions, or does it search code for TODO/FIXME/XXX markers? Rewrite description to match implementation. If both, split into two tools.
• Add output schema documentation: specify the JSON structure returned (e.g., {findings: [{id, severity, location}], score: number}). Include field types and meanings.
• Expand 'target' parameter description to specify format: 'A file path, directory path, or contract identifier (e.g., /path/to/contracts or 0x1234...). Relative paths are resolved from the current working directory.'
• Add error handling guidance: 'If target is not found, returns {findings: [], error: "path not found"}. If target is not readable, returns {findings: [], error: "permission denied"}.'
• Include a concrete example in the description: 'Call this to scan a Solidity contract directory for storage layout issues before upgrading a proxy. Returns a list of findings with severity levels (high, medium, low).' This disambiguates from generic code linters.