Critical gaps across all dimensions. No input schemas visible in source code, schema scores must be 0. Descriptions are present but generic (10-60 chars, below 20-char floor for most). No output schemas documented. No error handling guidance. No parameter validation rules. No tool annotations. HTTP transport claimed but no actual MCP server implementation visible in provided code, only Dockerfile and package.json with Slack dependencies.

• Create explicit tool registration in index.js with full JSON Schema input definitions. Example: { name: 'wazuh_get_alert', inputSchema: { type: 'object', properties: { alert_id: { type: 'string', description: 'Unique alert identifier (e.g., 1234567890.0)' } }, required: ['alert_id'] } }
• Expand tool descriptions to 100-200 chars. Include WHEN to use (vs similar tools), WHAT is returned, and PREREQUISITES. Example: 'Retrieve a single alert by ID. Use this when you have a specific alert ID; use wazuh_search_alerts to find alerts by query. Returns alert metadata, severity, and rule details.'
• Document output schemas for each tool. Specify which fields are always present (alert_id, timestamp, severity) vs optional (enrichment data). Include field types and descriptions.
• Add parameter constraints: alert_id format (regex or length), query syntax rules, limit bounds (1-1000). Example: { limit: { type: 'integer', minimum: 1, maximum: 1000, description: 'Max results (default 20)' } }
• Implement error handling with recovery guidance. Return structured errors: { error: 'alert_not_found', message: 'Alert 999 not found. Try wazuh_search_alerts with a time range.', retryable: false }

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

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