NmapTools exhibits fundamental structural deficiencies across naming, parameter documentation, output schemas, and error handling. While all 14 tools have descriptions and visible implementations, most descriptions are minimal (averaging ~60 chars, well below the 194-char baseline for A+ tools). Parameter documentation is sparse: optional parameters lack descriptions entirely (e.g., 'ports' in basic_port_scan is described as 'Optional port range...' but no guidance on format constraints), and critical parameters like 'mode' in stealth_scan lack enum constraints. Output schemas are entirely undocumented, the source code shows subprocess.run() returning stdout/stderr as plain text strings with no structure, pagination, or field documentation. Error handling is absent: tools return raw subprocess output or stderr with no recovery guidance. Input validation is missing: custom_scan accepts arbitrary command options (command injection risk), and stealth_scan has a minimal inline check but no structured error response. Tool naming follows verb_noun convention (basic_port_scan, detect_services) but several names are overly generic ('custom_scan' could be more specific; 'aggressive_scan' vs 'vulnerability_scan' are functionally unclear in distinction). No tools declare permissions, support idempotency, or offer confirmation workflows for destructive operations. The server provides one resource (nmap://welcome) offering a menu, which is helpful for discovery but does not substitute for structured parameter documentation.

• Document output schemas for each tool. Define return object structure (e.g., { ports: [{port: int, state: string, service: string}], scan_summary: {start_time, duration_ms, open_port_count} } for basic_port_scan). Include field types and descriptions so LLMs can extract and chain data.
• Add enum constraints to all parameters accepting known values. For stealth_scan, declare 'mode' as enum ['sN', 'sF', 'sX']. For run_nse_script, provide a list of common valid NSE script categories or link to discovery mechanism. For basic_port_scan, specify port format as pattern '\d+(-\d+)?(,\d+(-\d+)?)*'.
• Expand descriptions to 100 - 200 characters per the A+ baseline. Example: 'Scan open ports on a target using a SYN scan. Specify ports as a range (e.g., "20-80") or comma-separated list (e.g., "22,80,443"). Returns list of open ports and services. Use this for initial reconnaissance. Requires network access to target.'
• Implement structured error responses. Return JSON with {success: bool, error_code: string, message: string, recovery_hint: string} instead of raw subprocess output. Example: {success: false, error_code: 'INVALID_PORT_RANGE', message: 'Port range must be 1 - 65535', recovery_hint: 'Try a valid range like "1-1024" or specific ports "22,80"'}.
• Sanitize command input in custom_scan and scan_to_file. Build command with explicit flag validation or an allowlist rather than split(). Example: custom_scan should accept structured parameters (e.g., {'scan_type': 'sS', 'aggressive': bool, 'timing': 'paranoid|sneaky|polite|normal|aggressive'}) instead of free-form options string.