Single tool 'cspbuilder_scan' has a basic description (89 chars) and minimal input schema. The tool name lacks a clear action verb (scan is acceptable but vague about CSP generation vs. audit). Input parameter 'target' has a description but no type constraints, format guidance, or examples. No output schema is documented, the tool returns JSON but the structure is not formally specified. No error handling guidance, no parameter validation rules, and no indication of what fields the JSON response contains. The implementation is simple but the tool definition falls short of production standards.

• Document the output schema explicitly. Specify that the response is JSON with fields: 'tool' (string), 'findings' (array of {id, sev, where}), 'score' (number). Include example output.
• Add format and validation rules to 'target' parameter: 'Target URL (http/https) or file system path. Max 2048 chars. Must be reachable and readable.'
• Expand tool description to clarify scope: 'Scans a URL or local HTML file for CSP policy generation. Extracts resource directives and returns findings with severity levels.' Add: 'Returns JSON with findings array and overall score.'
• Add error handling guidance: 'If target is unreachable, returns error with retry guidance. If path does not exist, returns clear file-not-found message with available alternatives.'
• Consider renaming to 'generate_csp_from_scan' or 'audit_csp_policy' to make intent clearer, or split into two tools if generation and audit are distinct workflows.