An MCP server for analyzing network traffic using Wireshark's tshark command-line tool. Provides tools for live packet capture, file-based packet analysis, and network traffic filtering.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The Wireshark MCP server exposes 8 tools for network packet analysis via Wireshark/tshark. While tool names are reasonable action verbs (capture_live, analyze_pcap_file, extract_*), descriptions are generic 3-10 character Chinese strings that provide minimal context for LLM selection. Input schemas are present and mostly well-typed, but descriptions lack actionable depth (e.g., 'BPF filter expression' is mentioned but constraints/examples are absent). Output schemas are not documented in the tool definitions, responses are handled internally by _format_json_output() but LLMs cannot see what fields to expect. Error handling is minimal (basic JSON decode try-catch, no recovery guidance). No tool annotations (readOnlyHint, etc.) despite all tools being read-only. Parameter descriptions are brief and lack examples or format hints. The code does show good internal validation (_validate_max_packets, _validate_file_path), but this is invisible to the calling LLM. No pagination documented for tools that could return large result sets (e.g., analyze_pcap_file with max_packets parameter suggests batching, but no offset/limit pattern).
Descriptions are trivially short (3-10 chars) and non-English, providing almost no context for LLM tool selection. E.g., '实时抓包' (capture live), '分析 PCAP 文件' (analyze PCAP file). LLMs cannot determine WHEN to use each tool or what distinguishes them.
No output schemas documented for any tool. While _format_json_output() wraps responses in a status/metadata/data envelope, the tool definitions do not declare this structure. LLMs cannot plan downstream tool calls or know what fields are available.
Expand every tool description to 50-150 characters in English. Example for capture_live: 'Capture live network packets from a specified interface for real-time traffic analysis. Filters packets using BPF expressions (e.g., tcp port 80). Returns JSON-formatted packet details. Use list_network_interfaces first to discover available interfaces.' This answers WHAT, WHEN to use it, and any prerequisites.
Add output schema documentation to each tool definition. Document the wrapper envelope (status, metadata, data) and per-tool payload structure. E.g., analyze_pcap_file should declare: 'Returns: {status: "success"|"error", metadata: {timestamp, tshark_version}, statistics: {total_packets, returned_packets, truncated}, data: [{packet_number, src, dst, protocol, info}, ...]}'.
Convert parameter descriptions to format constraints. For 'filter', write: 'BPF filter expression (e.g., tcp port 80, ip.src==192.168.1.0/24). See https://www.wireshark.org/docs/man-pages/pcap-filter.html. Leave empty for no filtering.' For output_format, declare enum: ["json", "csv", "text"].
Add tool annotations to all tools. Declare readOnlyHint=true and idempotentHint=true for all 8 tools to signal safe, repeatable calls and reduce LLM caution.
Implement per-tool error handling with actionable recovery messages. Example: if file_path does not exist, return {status: 'error', message: 'PCAP file not found: /path/to/file.pcap. Verify the path and try again, or use analyze_pcap_file with a valid file path from your working directory.'}. Categorize as 'user-fixable'.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions are bare identifiers with no format guidance, constraints, or examples. E.g., 'BPF filter expression' does not explain valid syntax, common mistakes, or provide examples like 'tcp port 80 and ip.src==192.168.1.1'.
output_format parameter in analyze_pcap_file is missing enum constraint. Description says '(json, csv, text)' but this is only in description text, not as a formal enum in schema. LLMs may hallucinate other formats like 'xml' or 'yaml'.
conversation_type parameter in get_conversation_statistics is missing enum constraint in schema. Description lists '(ip, tcp, udp, http)' but should be a formal enum to prevent LLM from passing invalid values.
No tool annotations (readOnlyHint, idempotentHint, etc.) despite all 8 tools being read-only. This forces LLMs to reason conservatively about idempotency and safety, increasing context cost.
Error handling is minimal. _format_json_output() catches JSONDecodeError but does not guide the LLM on next steps. Errors like 'file not found' or 'tshark command failed' would be returned as raw strings without categorization (retryable vs fatal) or recovery suggestions.
Parameter 'interface' in capture_live is a free-form string with no enum or validation hints. Valid interface names depend on the OS (e.g., 'eth0' on Linux, 'en0' on macOS, 'Wi-Fi' on Windows). LLMs cannot know what to pass without calling list_network_interfaces first.
No pagination documented. Tools like analyze_pcap_file accept max_packets but do not declare offset/limit or cursor patterns. Large result sets could exceed context limits, but LLMs have no way to paginate.
Chinese descriptions and field names (e.g., '实时抓包', '抓包持续时间') make the tool inaccessible to non-Chinese-speaking users and LLM providers. Tool definitions should use English.
Replace free-form 'interface' parameter with enum or discovery pattern. Either (1) declare enum of common interfaces in description, or (2) document: 'Call list_network_interfaces first to see available options, then pass the name from the response.' Add dependency hint to capture_live description.
Clarify pagination. For tools returning potentially large datasets (analyze_pcap_file, extract_http_requests, extract_dns_queries, extract_tls_certificates), add offset and limit parameters alongside max_packets. Document: 'Returns up to limit packets starting at offset. total_count in response indicates how many more are available.'
Translate all descriptions and parameter names to English. Replace Chinese with clear English prose. This broadens accessibility and compatibility with international LLM providers.
Validate and document tshark version requirements. The server calls _get_tshark_version() but does not declare minimum tshark version or known incompatibilities. Add a note: 'Requires tshark >=3.4.0. Tested with tshark 4.0.x.'
Add examples to parameter descriptions using description text, not as example values in the schema. E.g., 'duration: Capture time in seconds (e.g., 30 for 30 seconds). Must be 1-3600.' Avoid listing example IDs; instead describe the format.