This MCP server exposes 27 security-sensitive tools (network scanning, binary analysis, packet capture) with critically minimal safeguards. All tools share a uniform, incomplete definition pattern: single parameter ('target' or 'pcap_file'), vague descriptions (15-50 chars, well below the 50-200 char LLM-optimized baseline), no input validation guidance, no error handling strategy, and no destructive operation warnings. The descriptions are too terse to guide LLM tool selection, they lack context on when to use each variant, what prerequisites exist, or what the output structure is. Parameter schemas are visible but trivial (single string fields with minimal metadata). Most critically, this server exposes dangerous operations (network scanning, packet sniffing, disassembly) without permission gates, audit trails, or scope declarations. The 'IS_SAFE=false' environment variable indicates no execution sandbox. No tool declares whether it requires elevation, network access, or produces irreversible side effects.
Tools (27)
analyze_pcapread onlysource verified45/100
Perform an analysis of a pcap file using tshark.
basic_scanread onlysource verified43/100
Perform a basic network scan using nmap.
basic_stringsread onlysource verified42/100
Perform a basic string listing using strings.
basic_symbolsread onlysource verified42/100
Perform a basic symbol listing using nm.
capture_liveread onlysource verified45/100
Perform a live capture of network traffic using tshark.
All 27 tools have descriptions under 50 characters, far below the 50-200 char LLM-optimized baseline. Descriptions like 'Perform a basic network scan using nmap.' (41 chars) lack context on when to choose this variant over 'intense_scan', what the output format is, or what prerequisites exist. LLMs cannot reliably select the right tool without context.
Expand all descriptions to 100-150 characters minimum. For each nmap scan variant, clarify: 'Conduct a [TYPE] scan to [OBJECTIVE]. Use this when [SCENARIO]. Returns nmap output in text format; parse to extract open ports and service versions.'
Document output format for every tool. E.g., 'Returns: String containing nmap output with one line per discovered port in format: PORT/STATE/SERVICE/VERSION. Parse to extract the ports list.' This guides LLM parsing logic.
Add parameter validation descriptions: 'target: IP address (A.B.C.D), CIDR notation (A.B.C.D/N), or hostname (RFC 1123). Must be reachable from this host. Examples: 192.168.1.1, 10.0.0.0/8, example.com'
Add @tool decorator annotations (readOnlyHint=True for all tools since none modify local system state). This signals to clients that tools are safe to retry.
Implement input validation in each tool function. Example: 'def basic_scan(target: str): if not is_valid_ip_or_hostname(target): return "Error: Invalid target. Must be IP (A.B.C.D), CIDR (A.B.C.D/N), or hostname. Got: " + target'
Add error recovery guidance. E.g., if nmap fails with 'Permission denied', suggest 'This tool requires elevated privileges. Consider: (1) Run the server with sudo. (2) Verify the target is accessible from this host. (3) Check local firewall rules.'
Implement per-tool timeouts and graceful failures. Nmap scans can hang; set a 60-second default timeout and return 'Scan timed out after 60s. Target may be unreachable or firewall-blocked.'
Score history
Overall score trend
↑ 45 points across a rubric change (v1 → v2)
45/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
45
2026-07-28+
v2
2026-03-09
F
0
-
v1
source verified
43/100
Perform a disassembly of the target file using objdump.
dynamic_symbolsread onlysource verified42/100
Perform a dynamic symbol listing using nm.
encoding_stringsread onlysource verified42/100
Perform an encoding string listing using strings.
expert_inforead onlysource verified42/100
Perform an expert information listing using tshark.
extract_httpread onlysource verified43/100
Perform an HTTP extraction from a pcap file using tshark.
file_headersread onlysource verified42/100
Perform a file header listing using objdump.
full_contentsread onlysource verified42/100
Perform a full contents listing using objdump.
intense_scanread onlysource verified43/100
Perform an intense network scan using nmap.
min_length_stringsread onlysource verified45/100
Perform a minimum length string listing using strings.
numeric_sortread onlysource verified42/100
Perform a numeric sort of symbols using nm.
offset_stringsread onlysource verified42/100
Perform an offset string listing using strings.
protocol_hierarchyread onlysource verified43/100
Perform a protocol hierarchy listing using tshark.
No output schema documented for any tool. Descriptions say 'Returns: str: The output results of...' but LLMs need to know the structure of that string. Are results formatted as JSON, YAML, plain text? Does the LLM need to parse raw command output or call another tool first?
Security-critical tools (nmap scanning, tshark packet capture, binary disassembly) have no permission gates, scope declarations, or destructive operation warnings. No @tool decorator uses readOnlyHint or destructiveHint annotations. The Dockerfile sets 'IS_SAFE=false', indicating commands run uncontained. No audit trail, no permission checks, no rate limiting.
Parameter 'target' appears in 22 tools with identical, non-specific descriptions ('The target IP address or hostname to scan' or 'The target file or executable to analyze'). No validation guidance (IP format, hostname pattern, file path restrictions). No indication of acceptable ranges or formats. LLMs cannot validate input before passing it.
No error handling strategy. Calling 'nmap' on a non-existent hostname, an invalid IP, a file that doesn't exist, or a permission-denied path will return raw command stderr. The tool offers no guidance on recovery, LLMs see a wall of text and cannot self-correct.
Tool naming uses descriptive adjectives (basic_, intense_, stealth_, quick_) to distinguish nmap variants and symbol-listing variants, but provides no context in descriptions for LLMs to choose the right one. 'When should I call stealth_scan vs quick_scan?' is unanswered. This forces guesswork or trial-and-error.
No indication of which tools require system privileges, network access, or external tools (nmap, tshark, binutils, etc.). If Kali tools are missing, tools fail silently. LLMs cannot plan around missing dependencies.
Parameter schemas for capture_live and analyze_pcap are more complex (multiple params) but lack any constraint on values. 'duration' has no min/max (could request 999999 seconds). 'filter' and 'display_filter' accept free-form strings with no validation or escaping, inviting injection attacks on tshark.
capture_liveanalyze_pcap
For nmap variants, add a discovery tool like 'list_scan_types()' that returns: 'basic: Quick port enumeration (10 common ports). intense: Full port + service version detection (slow). stealth: IDS-evasion mode. quick: 100 common ports. vulnerability: Scan with NSE scripts.' This enables LLM selection without trial-and-error.
Add permission checks and audit logging. Before executing any tool, log: caller_id, tool_name, parameters (sanitized), timestamp, result. Implement scope declarations: 'scan:nmap=read-network', 'analyze:binary=read-filesystem'.
Cap result sizes and add pagination. If nmap returns 10000+ lines of output, return the first 50 lines + a marker 'Results truncated. Use apply parse_nmap_output(raw_output) to extract structured data.' This prevents context explosion.
Rename similar tools for clarity. Instead of 'basic_scan' + 'intense_scan', use 'scan_ports_quick' + 'scan_ports_deep_with_version'. This makes intent explicit without reading descriptions.