Mcpcap

What mcpcap does

The mcpcap MCP server turns PCAP analysis into callable MCP tools. It accepts either a path visible to the server or an HTTP(S) URL supplied at invocation time, then returns structured JSON intended for consumption by language models and other MCP clients. Because capture locations are provided per call, the service does not need to maintain capture state between requests.

Supported analysis areas include DNS, DHCP, ICMP, TCP, SIP, and CapInfos. The TCP module covers connection lifecycles, traffic patterns, retransmissions, and bidirectional flow behavior. The other protocol modules extract protocol-specific events, participants, options, responses, and related observations from packet captures.

How it works

mcpcap uses Scapy for packet parsing and organizes analysis by protocol module. Start the process with the default stdio transport for a locally spawned client, or select HTTP transport and expose the /mcp endpoint for a client that connects over a network. Modules can be restricted at startup, such as dns,tcp, and packet processing can be bounded with --max-packets.

A tool call supplies the capture location and, where supported, filters or analysis options. TCP tools can filter by server address and port; connection analysis also accepts a detailed-output option, retransmission analysis accepts a threshold, and flow analysis requires a server address. Local captures mounted into Docker must be referenced using their container path.

Setup and configuration

Python 3.10 or newer is required. Install the package with pip or uv, run it once with uvx, or build and run the supplied Docker image. Docker Compose provides an HTTP setup that mounts an example capture directory at /pcaps; replace that volume with the directory containing your own captures.

For local MCP clients, launch mcpcap through stdio. For HTTP clients, run with --transport http, configure the host and port, and use the resulting /mcp URL. Binding HTTP on a non-loopback interface requires the MCPCAP_AUTH_TOKEN environment variable. Clients then send the token as a bearer credential. A TLS reverse proxy is recommended for remote access. The unauthenticated HTTP option is shown for container deployments published only to host loopback.

Tools and capabilities

The mcpcap MCP server provides these tools:

• analyze_dns_packets: extracts DNS queries, responses, names, record types, frequencies, and potential issues.
• analyze_dhcp_packets: examines DHCP exchanges, clients, servers, leases, options, and anomalies.
• analyze_icmp_packets: analyzes echo traffic, response timing, TTLs, routing-related data, and ICMP errors.
• analyze_tcp_connections: tracks handshakes, termination, successful or failed connections, and abnormal closure patterns.
• analyze_tcp_anomalies: reports observed flags, resets, retransmissions, and lifecycle metrics.
• analyze_tcp_retransmissions: calculates overall and per-connection retransmission rates against a configurable threshold.
• analyze_traffic_flow: compares both traffic directions and identifies asymmetry and reset sources.
• analyze_sip_packets: parses SIP signaling in VoIP captures.
• analyze_capinfos: returns capture information for a PCAP file.

Limitations and notes

The server analyzes packet captures; it does not provide live packet capture collection. Remote input is limited to HTTP(S) URLs, and local input must be accessible from the process or container. Docker users must use container paths for mounted files. HTTP authentication applies according to the selected bind configuration, while stdio is unaffected. Analysis scope and processing cost can also be limited with module selection and --max-packets.