WiFi PCAP Analyzer MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TSHARK_PATH | No | Full path to the tshark executable. If not set, the server checks PATH and the standard Windows installation directory (C:\Program Files\Wireshark\tshark.exe). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| load_captureA | Register a local packet-capture file for subsequent analysis. Call this before using tools that accept Args:
capture_id: Non-empty session-unique name chosen by the caller, such as
Returns: Load status, normalized capture ID, resolved path, file name, and size. |
| list_loaded_capturesA | List every capture registered in the current MCP server session. Use this to discover available capture IDs or confirm load/reload/unload operations. It reads only in-memory metadata and never rescans capture contents. Decryption-key values are never returned. Returns: Capture count and metadata for each capture, including path, size, modification/load times, revision, and decryption-key configuration. |
| unload_captureA | Remove a loaded capture from the current server session. This forgets the capture metadata and any configured decryption keys. It never deletes or changes the source PCAP/PCAPNG file. Args:
capture_id: ID previously supplied to Returns:
The removed capture ID and an |
| reload_captureA | Refresh a loaded capture after its source file changes. The tool verifies the original file again, updates its path, size, modification time, and load time, and increments the capture revision. It does not scan packets during the reload. Args: capture_id: ID of a currently loaded capture. clear_decryption_keys: When true, remove all keys stored for this capture. The default preserves them. Returns:
Refreshed metadata, new revision number, and a |
| set_decryption_keysA | Configure Wi-Fi decryption keys for later packet analysis. Keys exist only in server memory and are passed to TShark whenever the
capture is read. Secret values are never included in tool responses or
normal logs. Supported key types are Args:
capture_id: ID of a currently loaded capture.
keys: Key objects containing Returns: Capture ID, configured key count, and key types. Values are omitted. |
| export_filtered_captureA | Write packets matching a display filter to a new capture file. The export uses a temporary file and replaces the destination only after TShark succeeds. It never allows the source capture to be overwritten. Configured decryption keys are applied while filtering. Args:
capture_id: ID of a currently loaded capture.
filter_expression: Non-empty Wireshark display filter selecting packets.
output_path: Destination ending in Returns: Capture ID, normalized filter, resolved output path, name, and size. |
| get_summaryA | Produce a quick packet-level overview of a loaded capture. This iterates through the full capture and is useful as the first analysis call after loading. It reports packet count, observed protocol-layer names, first/last Unix timestamps, and duration. Args: capture_id: ID of a currently loaded capture. Returns: Packet count, sorted protocols, start/end timestamps, and duration. |
| get_capture_metadataA | Inspect PCAP/PCAPNG container and capture-interface metadata. Use this for file format, encapsulation, snap length, timestamp precision, capture origin, comments, time range, and per-interface information. The result comes primarily from Capinfos and does not return packet dissections. Args: capture_id: ID of a currently loaded capture. Returns: File, timing, capture-host, and interface metadata when available. |
| get_capture_statisticsA | Calculate aggregate traffic rates and packet-size statistics. This combines Capinfos totals with a TShark pass over frame lengths. Use it to assess capture volume, duration, average traffic rate, and minimum, maximum, and average packet sizes. Args: capture_id: ID of a currently loaded capture. Returns: Packet/byte totals, file size, timing, rates, and packet-size metrics. |
| validate_captureA | Validate capture readability and identify common packet-quality issues. Checks malformed packets, captured-length truncation, missing core frame fields, severe decode failures, unsupported protocols, timestamps, and strict chronological order. Issue categories can overlap. Args: capture_id: ID of a currently loaded capture. example_limit: Maximum frame numbers retained for each issue, from 0 through 100. Counts always include all matches. Returns: Overall validity/readability, packet count, time-order status, and issue counts with example frame numbers. |
| get_capture_interfacesA | List capture interfaces or radio adapters stored in the file. This is a focused view of Args: capture_id: ID of a currently loaded capture. Returns: Interface count and available names, link types, snap lengths, timestamp precision, operating systems, and packet counts. |
| get_capture_time_rangeA | Divide the capture time range into packet and byte-count buckets. Use this to locate bursts, quiet intervals, or the portion of a capture worth filtering in more detail. Every packet is assigned to one evenly sized time bucket. Args: capture_id: ID of a currently loaded capture. bucket_count: Number of buckets to generate, from 1 through 100. Defaults to 20. Returns: Overall time range plus timestamped packet/byte totals per bucket. |
| filter_packetsA | Find packets using a Wireshark/TShark display-filter expression. Use standard display filters such as Args: capture_id: ID of a currently loaded capture. filter_expression: Non-empty Wireshark display filter. This is not a BPF/libpcap capture filter. limit: Maximum results to return, from 1 through 1000. Defaults to 100. Returns: Normalized filter, match count returned, and packet summaries containing frame number, Unix timestamp, protocols, and textual dissection. |
| dissect_packetA | Return the decoded protocol layers and fields for one frame. Frame numbers are the one-based Args: capture_id: ID of a currently loaded capture. packet_number: Positive, one-based Wireshark frame number. Returns: Capture/frame identity, found flag, packet summary, and decoded fields grouped by protocol layer when the frame exists. |
| get_packet_by_numberA | Retrieve and fully decode one packet by its Wireshark frame number. This is a lookup-oriented alias of Args: capture_id: ID of a currently loaded capture. packet_number: Positive frame.number value. Returns: Capture/frame identity, found flag, packet summary, timestamp, protocol list, and decoded fields grouped by layer. |
| get_packets_by_time_rangeA | Retrieve packets whose Unix timestamps fall within an inclusive range. Times use seconds since the Unix epoch, matching Args: capture_id: ID of a currently loaded capture. start_time: Inclusive Unix epoch start time. end_time: Inclusive Unix epoch end time. limit: Maximum number of packets, from 1 through 1000. Returns: Requested range, normalized display filter, returned packet count, truncation flag, and packet summaries. |
| get_packets_between_framesA | Retrieve packets in an inclusive Wireshark frame-number range. Both range boundaries are included. Results contain compact packet summaries so a caller can select individual frames for detailed dissection without decoding every field in the requested range. Args: capture_id: ID of a currently loaded capture. start_frame: Inclusive first frame number. end_frame: Inclusive last frame number. limit: Maximum number of packets, from 1 through 1000. Returns: Requested frame range, generated display filter, returned count, truncation flag, and packet summaries. |
| get_related_packetsA | Find packets related to a selected packet or connection event. Correlation prefers exact TCP/UDP stream or DNS/DHCP transaction IDs, then falls back to Wi-Fi client/BSSID, IP, or Ethernet endpoints. Endpoint-based results are explicitly marked as heuristic and bounded by time. Args: capture_id: ID of a currently loaded capture. packet_number: Positive, one-based source frame number. window_seconds: Seconds before and after the source packet to search; must be greater than zero and no more than 3600. limit: Maximum results to return, from 1 through 1000. Returns: Source-frame status, correlation method and confidence, generated display filter, truncation flag, and related packet summaries. |
| get_packet_timelineA | Generate a chronological timeline of packet events. The optional expression is a Wireshark display filter, not a capture filter. Events include deltas from the previous timestamp and elapsed time from the first returned event, making exchanges easier to inspect. Args: capture_id: ID of a currently loaded capture. filter_expression: Optional Wireshark display filter. limit: Maximum number of timeline events. Returns: Ordered events containing frame, timestamp, delta, elapsed time, protocols, textual summary, result count, and truncation status. |
| get_flow_packetsA | Retrieve packets belonging to a decoded transport or application flow. Flow IDs are TShark stream identifiers, not port numbers. TLS and HTTP
flows use their underlying Args: capture_id: ID of a currently loaded capture. flow_type: One of tcp, udp, quic, tls, or http. flow_id: Non-negative TShark stream identifier. limit: Maximum results to return, from 1 through 1000. Returns: Normalized flow type and ID, generated display filter, packet count, truncation flag, and matching packet summaries. |
| get_client_packetsA | Retrieve IEEE 802.11 packets involving a Wi-Fi client MAC address. The query uses Args:
capture_id: ID of a currently loaded capture.
client_mac: Client MAC address such as Returns: Normalized client MAC, generated display filter, packet count, truncation flag, and matching packet summaries. |
| get_ap_packetsA | Retrieve IEEE 802.11 packets associated with an access-point BSSID. The query uses the decoded Args:
capture_id: ID of a currently loaded capture.
bssid: AP/BSSID MAC address such as Returns: Normalized BSSID, generated display filter, packet count, truncation flag, and matching packet summaries. |
| get_transaction_packetsA | Retrieve packets belonging to a DNS, DHCP, TCP, EAPOL, or ARP exchange. DNS and DHCP keys may be decimal or Args: capture_id: ID of a currently loaded capture. transaction_type: One of dns, dhcp, tcp, eapol, or arp. transaction_key: Protocol-specific ID, stream, MAC, or IPv4 address. limit: Maximum results to return, from 1 through 1000. Returns: Normalized transaction type and key, generated display filter, packet count, truncation flag, and matching packet summaries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Most tools are clearly separated into lifecycle, metadata, and packet-retrieval roles, and the descriptions are detailed about input types. However, dissect_packet and get_packet_by_number are explicit aliases, and several TCP/DNS retrieval tools overlap enough to create misselection risk.
All tool names follow a consistent snake_case verb_noun pattern with predictable prefixes like load_, get_, set_, and filter_. Singular/plural noun choices are consistent with the returned data, and even the redundant get_packet_by_number is name-consistent.
At 23 tools, the server sits in the heavy 16-25 range and is borderline appropriate for a full PCAP analyzer. The count is defensible given the breadth of metadata, validation, and Wi-Fi-specific retrieval features, but the duplicate dissection tool and overlapping retrieval variants mean it could be trimmed without losing capability.
The server covers capture lifecycle, decryption-key configuration, export, metadata and statistics, validation, timeline analysis, generic filtering, per-frame dissection, and Wi-Fi-specific client/AP/transaction views. No major operational gap is apparent for file-based WiFi packet-capture analysis.