Five tools with complete schemas and descriptions. Naming follows verb_noun convention (scan_site, get_core_score, list_checks, explain_check, get_finding). Descriptions are adequate (50-150 chars) and explain purpose clearly. All parameters have types and descriptions. However, descriptions lack actionable context for LLM selection (e.g., when to call scan_site vs get_core_score), parameter constraints are minimal (no enums, ranges, or format specs), and output schemas are not documented. Error handling guidance is absent. Security posture is good (READ_ONLY classification, no secrets exposed), but composition could be tighter, get_finding requires a prior scan_id, creating implicit state dependency not documented in descriptions.

• Document output schemas for all tools. For scan_site, specify: returns {findings: [{id, category, severity, evidence}], scan_id, timestamp} or similar. For list_checks, specify: returns {checks: [{id, category, weight, profiles, experimental}], total}.
• Convert 'profile' and 'format' parameters to enums with explicit allowed values. E.g., profile: enum ['auto', 'strict', 'lenient'] with descriptions for each.
• Enhance descriptions with LLM-optimized context. E.g., scan_site: 'Scan a URL for AI-agent readiness signals (robots.txt, llms.txt, structured data). Use this for full analysis; use get_core_score for a quick score only.'
• Document the scan_id → get_finding dependency explicitly. E.g., get_finding description: 'Retrieve a specific finding from a scan. Requires scan_id from a prior scan_site call. Returns {finding: {id, category, severity, evidence, remediation}}.'
• Add error recovery guidance. E.g., scan_site: 'If scanning fails on localhost, set allow_private_networks=true. If URL is invalid, verify it starts with http:// or https://. If timeout occurs, try a simpler URL or contact support.'