The server implements 2 tools for asynchronous Nmap scanning with reasonable descriptions and partial schemas. Naming follows verb_noun convention (start_nmap_job, get_nmap_status). Descriptions are detailed (200+ chars each) and explain purpose, parameters, returns, and notes. However, schema quality varies: start_nmap_job has complete input schema with types and descriptions; get_nmap_status lacks a formal schema in the provided code (parameter documented in docstring only). Output schemas are undocumented, responses are inferred from docstring examples. Parameter validation lacks constraint documentation (no enums for profile, no bounds on target format). Error handling is minimal, no recovery guidance, no validation errors returned, no permission checks. The composition is reasonable (two focused, chainable tools), but lacks idempotency guarantees and doesn't address edge cases like invalid job_id or malformed targets. Security concerns: no input sanitization visible for command injection risks (nmap arguments are shell-executed), no audit logging, no rate limiting.

• Add formal JSON Schema to get_nmap_status input (wrap job_id parameter in Pydantic model or explicit schema definition).
• Document output schemas for both tools using Pydantic response models or JSON Schema. Example: 'Returns {"job_id": string, "status": "queued"}'.
• Convert profile parameter to an enum constraint: profile must be one of [quick, quick-plus, port-1k, ...]. Reference nmap_profiles.py in schema.
• Add input validation: target must match IPv4/IPv6 or hostname regex; reject CIDR notation unless explicitly supported. Return 'Invalid target format' error with pattern.
• Sanitize extra_args to prevent command injection. Whitelist allowed nmap flags or escape/validate each argument before shell execution.
• Update get_nmap_status to return {"status": "error", "error": "Job not found: <job_id>. Check spelling or call start_nmap_job to begin a new scan."} when job_id is invalid.
• Add idempotency key support: accept optional 'idempotency_key' parameter; return same job_id if called again with same key within a time window.
• Document timeout and resource limits in descriptions. Example: 'Scans timeout after 1 hour. Use quick or top-ports-100 profiles to reduce runtime.'
• Add audit logging: log who called each tool, with target, profile, timestamp, and result (async: job queued, job completed, error).
• Implement rate limiting: track jobs per user/session; reject new scans if user has >N running jobs or >M jobs in last 10 minutes.