Server has 10 tools with consistent naming (verb_noun pattern) and basic descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are generic (avg ~60 chars, well below the 194-char baseline for A+ tools), lack context on WHEN to use each tool, and omit recovery guidance. No output schemas documented. Parameter descriptions are minimal. Missing error handling patterns, confirmation steps for destructive operations (start/stop capture), and field-level guidance. Tools are well-composed (single responsibility) but lack the depth needed for confident LLM selection.

• Expand tool descriptions to 100 - 200 chars. Include: (1) what the tool does, (2) when to use it vs similar tools, (3) what it returns. E.g., 'Analyze a pcap file to extract protocol-level insights (TCP/UDP/DNS/HTTP). Use this for high-level traffic patterns; use extract_http_requests for detailed HTTP payloads.'
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. E.g., list_captured_files should return [{filename, size_bytes, created_at, duration_seconds}] with a total_count and optional next_cursor.
• Add error handling guidance to tool descriptions. E.g., 'If the interface is busy, the agent should wait 5 seconds and retry. If the interface does not exist, call list_network_interfaces first.'
• Add min/max bounds and format constraints to numeric/string parameters. E.g., 'duration: 1 - 3600 seconds', 'time_interval: 1 - 300 seconds', 'limit: 1 - 1000'.
• Implement a dry-run or confirmation pattern for start_packet_capture and stop_packet_capture. E.g., add an optional 'confirm' parameter or return a confirmation_token that must be passed to a confirm_capture tool.

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

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