Four tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. Tool names follow verb_noun convention (kali-exec, kali-container-status, kali-container-restart, kali-container-stop), which is good. However, descriptions lack depth on when to use each tool vs. alternatives, and parameter descriptions are minimal. No documented output schemas. Error handling is present in code but not surfaced in tool definitions. The 'kali-exec' tool is high-risk (IRREVERSIBLE) but lacks confirmation/dry-run pattern. Average description length ~80 chars (below 194-char baseline). Parameters have types but lack constraints (e.g., no enum for image, no validation rules).

• Document output schemas for all tools. E.g., kali-exec returns {stdout: string, stderr: string, exitCode: number}. kali-container-status returns {containerName: string, status: string, image: string}.
• Add parameter constraints: image should accept 'kalilinux/kali-rolling' or custom image URIs; containerName should match Docker naming rules (alphanumeric, dash, underscore, max 64 chars).
• Expand tool descriptions to 100-200 chars. Include when to use each tool: 'Use kali-exec to run commands inside the container. Use kali-container-restart if the container becomes unresponsive. Use kali-container-stop to free resources.'
• Implement dry-run or confirmation pattern for kali-exec. Add optional 'dryRun: boolean' parameter that returns the command without executing, or require explicit confirmation for destructive commands.
• Add error recovery guidance: 'If kali-exec fails with exit code 127, the command was not found. Verify the command is available in the Kali image.' Include common error codes and remediation steps.

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

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