Server has 6 tools with explicit registration, descriptions, and partial schemas. Naming follows verb_noun convention (list_, spring_, batch_). Descriptions are present (avg ~120 chars) but lack actionable context for LLM selection. Input schemas visible in code but incomplete: most parameters lack type constraints, enums, or validation guidance. Output schemas are structured (JSON objects) but not formally documented in tool definitions. Error handling exists (checkScope validation, audit logging) but lacks recovery guidance. Security model is sound (scope whitelist, exploit gating, audit trail) but not declared in tool metadata.

• Add JSON Schema constraints to all numeric/array parameters: threads (min=1, max=100), cves (minItems=0, maxItems=50), dict_path (pattern for file paths). Include these in parameter descriptions.
• Formally document output schemas in MCP tool registration. Add 'outputSchema' field to each mcp.Tool definition with typed fields, descriptions, and examples.
• Enhance error messages with recovery guidance: 'Target 192.168.1.1 not in scope [10.0.0.0/8]. Allowed: [10.0.0.0/8, 172.16.0.0/12]. Retry with a valid target or contact admin.'
• Expand tool descriptions to include WHEN/WHY: 'Call spring_fingerprint first to confirm Spring/Boot before running spring_vuln_detect. Returns confidence level to guide next steps.'
• Implement confirmation pattern for spring_exploit: add 'dry_run' boolean parameter (default true) to preview exploitation without executing. Require explicit dry_run=false for actual RCE/file access.