This server has critical definition gaps. Tool names lack action verbs (health, scan, scan_status, scan_results instead of get_health, start_scan, get_scan_status, get_scan_results). Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Input schemas exist but lack parameter descriptions, the 'options' parameter in scan is typed as object with no field documentation. Output schemas are completely undocumented; callers cannot know what fields to expect. Error handling is minimal (generic 500 errors, no recovery guidance). The scan tool combines multiple concerns (validate, generate ID, start async operation). No tool annotations (readOnlyHint, destructiveHint). Code shows async scan logic but tool definitions do not reflect idempotency or state management implications.

• Rename tools to start with action verbs: health → get_health, scan → start_scan, scan_status → get_scan_status, scan_results → get_scan_results. This enables LLMs to parse intent from names.
• Document output schemas for all tools. E.g., health returns {status, zap.connected, zap.version, server.uptime, server.activeScanCount}. scan returns {status, scan_id}. scan_status returns {status, scan.id, scan.target, scan.progress, scan.phase}.
• Expand 'options' parameter description to list valid keys and their types. E.g., 'Custom scan options object. Valid keys: spider (boolean), ajax (boolean), timeout (number, seconds).'
• Add tool annotations: mark scan with destructiveHint=true (initiates security scan with side effects). Mark health, scan_status, scan_results with readOnlyHint=true.
• Enhance error messages with recovery guidance. E.g., 'Invalid scan type: baseline. Valid types: baseline, full, api. Call get_scan_types() to list all.' Return 404 with 'Scan not found. Active scans: [list IDs]' to enable discovery.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry