Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcpcap analyze dns packets from https://example.com/traffic.pcap"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A modular Python MCP (Model Context Protocol) Server for analyzing PCAP files. mcpcap enables LLMs to read and analyze network packet captures with protocol-specific analysis tools that accept local file paths or remote URLs as parameters (no file uploads - provide the path or URL to your PCAP file).
mcpcap uses a modular architecture to analyze different network protocols found in PCAP files. Each module provides specialized analysis tools that can be called independently with any PCAP file, making it perfect for integration with Claude Desktop and other MCP clients.
Stateless MCP Tools: Each analysis accepts PCAP file paths or URLs as parameters (no file uploads)
Modular Architecture: DNS, DHCP, ICMP, and CapInfos modules with easy extensibility for new protocols
Local & Remote PCAP Support: Analyze files from local storage or HTTP URLs
Scapy Integration: Leverages scapy's comprehensive packet parsing capabilities
Specialized Analysis Prompts: Security, networking, and forensic analysis guidance
JSON Responses: Structured data format optimized for LLM consumption
Related MCP server: TShark2MCP
mcpcap requires Python 3.10 or greater.
pip install mcpcapuv add mcpcapuvx mcpcapStart mcpcap as a stateless MCP server:
# Default: Start with DNS, DHCP, and ICMP modules
mcpcap
# Start with specific modules only
mcpcap --modules dns
# With packet analysis limits
mcpcap --max-packets 1000Configure your MCP client (like Claude Desktop) to connect to the mcpcap server:
{
"mcpServers": {
"mcpcap": {
"command": "mcpcap",
"args": []
}
}
}#Test Commit
Use the analysis tools with any PCAP file by providing the file path or URL (not file uploads):
DNS Analysis:
analyze_dns_packets("/path/to/dns.pcap")
analyze_dns_packets("https://example.com/remote.pcap")DHCP Analysis:
analyze_dhcp_packets("/path/to/dhcp.pcap")
analyze_dhcp_packets("https://example.com/dhcp-capture.pcap")ICMP Analysis:
analyze_icmp_packets("/path/to/icmp.pcap")
analyze_icmp_packets("https://example.com/ping-capture.pcap")CapInfos Analysis:
analyze_capinfos("/path/to/any.pcap")
analyze_capinfos("https://example.com/capture.pcap")analyze_dns_packets(pcap_file): Complete DNS traffic analysis
Extract DNS queries and responses
Identify queried domains and subdomains
Analyze query types (A, AAAA, MX, CNAME, etc.)
Track query frequency and patterns
Detect potential security issues
analyze_dhcp_packets(pcap_file): Complete DHCP traffic analysis
Track DHCP transactions (DISCOVER, OFFER, REQUEST, ACK)
Identify DHCP clients and servers
Monitor IP address assignments and lease information
Analyze DHCP options and configurations
Detect DHCP anomalies and security issues
analyze_icmp_packets(pcap_file): Complete ICMP traffic analysis
Analyze ping requests and replies with response times
Identify network connectivity and reachability issues
Track TTL values and routing paths (traceroute data)
Detect ICMP error messages (unreachable, time exceeded)
Monitor for potential ICMP-based attacks or reconnaissance
analyze_capinfos(pcap_file): PCAP file metadata and statistics
File information (size, name, link layer encapsulation)
Packet statistics (count, data size, average packet size)
Temporal analysis (duration, timestamps, packet rates)
Data throughput metrics (bytes/second, bits/second)
Similar to Wireshark's capinfos(1) utility
mcpcap provides specialized analysis prompts to guide LLM analysis:
security_analysis - Focus on threat detection, DGA domains, DNS tunneling
network_troubleshooting - Identify DNS performance and configuration issues
forensic_investigation - Timeline reconstruction and evidence collection
dhcp_network_analysis - Network administration and IP management
dhcp_security_analysis - Security threats and rogue DHCP detection
dhcp_forensic_investigation - Forensic analysis of DHCP transactions
icmp_network_diagnostics - Network connectivity and path analysis
icmp_security_analysis - ICMP-based attacks and reconnaissance detection
icmp_forensic_investigation - Timeline reconstruction and network mapping
# Load specific modules
mcpcap --modules dns # DNS analysis only
mcpcap --modules dhcp # DHCP analysis only
mcpcap --modules icmp # ICMP analysis only
mcpcap --modules dns,dhcp,icmp,capinfos # All modules (default)# Limit packet analysis for large files
mcpcap --max-packets 1000mcpcap --modules dns,dhcp,icmp,capinfos --max-packets 500mcpcap [--modules MODULES] [--max-packets N]Options:
--modules MODULES: Comma-separated modules to load (default: dns,dhcp,icmp,capinfos)
Available modules: dns, dhcp, icmp, capinfos
--max-packets N: Maximum packets to analyze per file (default: unlimited)
Examples:
# Start with all modules
mcpcap
# DNS analysis only
mcpcap --modules dns
# With packet limits for large files
mcpcap --max-packets 1000Example PCAP files are included in the examples/ directory:
dns.pcap - DNS traffic for testing DNS analysis
dhcp.pcap - DHCP 4-way handshake capture
icmp.pcap - ICMP ping and traceroute traffic
npm install -g @modelcontextprotocol/inspector
npx @modelcontextprotocol/inspector mcpcapThen test the tools:
// In the MCP Inspector web interface
analyze_dns_packets("./examples/dns.pcap")
analyze_dhcp_packets("./examples/dhcp.pcap")
analyze_icmp_packets("./examples/icmp.pcap")
analyze_capinfos("./examples/dns.pcap")mcpcap's modular design supports easy extension:
BaseModule: Shared file handling, validation, and remote download
Protocol Modules: DNS, DHCP, and ICMP analysis implementations
MCP Interface: Tool registration and prompt management
FastMCP Framework: MCP server implementation
MCP Client Request → analyze_*_packets(pcap_file)
→ BaseModule.analyze_packets()
→ Module._analyze_protocol_file()
→ Structured JSON ResponseCreate new protocol modules by:
Inheriting from BaseModule
Implementing _analyze_protocol_file(pcap_file)
Registering analysis tools with the MCP server
Adding specialized analysis prompts
Future modules might include:
HTTP/HTTPS traffic analysis
TCP connection tracking
BGP routing analysis
SSL/TLS certificate analysis
Network forensics tools
Both analysis tools accept remote PCAP files via HTTP/HTTPS URLs:
# Examples of remote analysis
analyze_dns_packets("https://wiki.wireshark.org/uploads/dns.cap")
analyze_dhcp_packets("https://example.com/network-capture.pcap")
analyze_icmp_packets("https://example.com/ping-test.pcap")
analyze_capinfos("https://example.com/network-metadata.pcap")Features:
Automatic temporary download and cleanup
Support for .pcap, .pcapng, and .cap files
HTTP/HTTPS protocols supported
When analyzing PCAP files:
Files may contain sensitive network information
Remote downloads are performed over HTTPS when possible
Temporary files are cleaned up automatically
Consider the source and trustworthiness of remote files
Contributions welcome! Areas for contribution:
New Protocol Modules: Add support for HTTP, BGP, TCP, etc.
Enhanced Analysis: Improve existing DNS/DHCP analysis
Security Features: Add more threat detection capabilities
Performance: Optimize analysis for large PCAP files
MIT
Python 3.10+
scapy (packet parsing and analysis)
requests (remote file access)
fastmcp (MCP server framework)
GitHub: github.com/mcpcap/mcpcap
Documentation: docs.mcpcap.ai
Website: mcpcap.ai
For questions, issues, or feature requests, please open an issue on GitHub.
Return metadata from a PCAP file, similar to Wireshark's capinfos utility.
IMPORTANT: This tool expects a FILE PATH or URL, not file content.
For local files: "/path/to/capture.pcap"
For remote files: "https://example.com/capture.pcap"
File uploads are NOT supported - save the file locally first
Args: pcap_file: Path to local PCAP file or HTTP URL to remote PCAP file (NOT file content - must be a path or URL)
Returns: A structured dictionary containing PCAP metadata including: - File information (size, name, encapsulation type) - Packet statistics (count, data size, average sizes) - Temporal data (duration, timestamps, rates)
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_file | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly explains the input requirement (path/URL, not content) and the return structure ('structured dictionary containing PCAP metadata'). It does not mention error handling or side effects, but for a read-only metadata tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an important note, args, and returns sections. Each sentence adds value: the main purpose, the input format warning, examples, and the output details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is complete. It covers input format, expected output, and even example paths. There are no gaps that would prevent correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter. It does: 'pcap_file: Path to local PCAP file or HTTP URL to remote PCAP file (NOT file content - must be a path or URL)' and even gives example formats. This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Return metadata from a PCAP file, similar to Wireshark's capinfos utility.' This is a specific verb and resource, clearly distinguishing it from sibling tools like analyze_dns_packets which analyze packet types rather than file metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'This tool expects a FILE PATH or URL, not file content' and 'File uploads are NOT supported - save the file locally first.' It does not explicitly mention alternatives, but the purpose is clear enough to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze DHCP packets from a PCAP file and return comprehensive analysis results. Then write data to user's system.
⚠️ FILE UPLOAD LIMITATION: This MCP tool cannot process files uploaded through Claude's web interface. Files must be accessible via URL or local file path.
SUPPORTED INPUT FORMATS:
Remote files: "https://example.com/capture.pcap"
Local files: "/absolute/path/to/capture.pcap"
UNSUPPORTED:
Files uploaded through Claude's file upload feature
Base64 file content
Relative file paths
Args: pcap_file: HTTP URL or absolute local file path to PCAP file
Returns: A structured dictionary containing DHCP packet analysis results
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_file | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently warns about the critical limitation regarding web-uploaded files and supports that with a detailed list of unsupported formats. However, the statement 'Then write data to user's system' is vague and unexplained, leaving uncertainty about a potentially impactful side effect (e.g., file system writes) without further detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings and each section serves a purpose, which aids readability. However, the 'Then write data to user's system' sentence appears out of place and confusing, and the format lists could be slightly tightened. Overall, it is appropriately sized for the information conveyed, with minor unnecessary elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the essential elements: the parameter's meaning, supported input formats, critical limitations, and the return type ('structured dictionary'). The only notable gap is the ambiguous 'write data' phrase, which if clarified would make the description fully complete. The output schema is present, so detailed return-value documentation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare string type with no description (0% schema coverage). The description fully compensates by explaining that pcap_file accepts an HTTP URL or absolute local file path, enumerating supported and unsupported input formats, and clarifying what the parameter represents. This gives the agent all necessary semantic information to populate the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Analyze DHCP packets from a PCAP file and return comprehensive analysis results,' which clearly identifies the tool's action and resource, and distinguishes it from sibling analyzers via the DHCP focus. However, the appended 'Then write data to user's system' introduces ambiguity about a secondary purpose or side effect, slightly undermining the clarity of the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit input format guidance, listing supported formats (URL, absolute local path) and unsupported ones (web-uploaded files, base64, relative paths). This gives clear context on when the tool can be used, but it does not reference sibling tools or explicitly state when to prefer DHCP analysis over DNS/ICMP/capinfos, leaving the choice of tool partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze DNS packets from a PCAP file and return comprehensive analysis results.
⚠️ FILE UPLOAD LIMITATION: This MCP tool cannot process files uploaded through Claude's web interface. Files must be accessible via URL or local file path.
SUPPORTED INPUT FORMATS:
Remote files: "https://example.com/capture.pcap"
Local files: "/absolute/path/to/capture.pcap"
UNSUPPORTED:
Files uploaded through Claude's file upload feature
Base64 file content
Relative file paths
Args: pcap_file: HTTP URL or absolute local file path to PCAP file
Returns: A structured dictionary containing DNS packet analysis results
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_file | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It warns about the file upload limitation, enumerates supported and unsupported input formats, and specifies the parameter type. It also discloses the return type ('structured dictionary'). This goes beyond a typical description, giving the agent essential behavioral knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: intro, warning, supported formats, unsupported formats, args, returns. Every sentence adds necessary information; the warning is important and the bullet lists are scannable. It is longer than average but each part earns its place, and the key limitation is front-loaded with the emoji alert.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no annotations, and an existing output schema, the description covers all necessary context: what it does, how to pass the file, what limitations exist, and what to expect in return. It explains the return value even though an output schema exists, and provides enough setup guidance to use the tool correctly. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows 'pcap_file' as a generic string with no description. The tool description compensates fully by defining it as an HTTP URL or absolute local file path, and by listing supported and unsupported formats. This provides crucial semantic meaning that the schema lacks entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Analyze DNS packets from a PCAP file'. This clearly distinguishes it from sibling tools like DHCP and ICMP analyzers. It also states the output type ('comprehensive analysis results'), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context ('Analyze DNS packets from a PCAP file') and clear when-not-to-use guidance via the unsupported inputs (web-uploaded files, base64, relative paths). However, it does not explicitly name alternative tools for other packet types, so it lacks the full 'alternatives' component for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze ICMP packets from a PCAP file and return comprehensive analysis results.
⚠️ FILE UPLOAD LIMITATION: This MCP tool cannot process files uploaded through Claude's web interface. Files must be accessible via URL or local file path.
SUPPORTED INPUT FORMATS:
Remote files: "https://example.com/capture.pcap"
Local files: "/absolute/path/to/capture.pcap"
UNSUPPORTED:
Files uploaded through Claude's file upload feature
Base64 file content
Relative file paths
Args: pcap_file: HTTP URL or absolute local file path to PCAP file
Returns: A structured dictionary containing ICMP packet analysis results
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_file | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It goes beyond trivial by explaining the file upload limitation (web upload unsupported), specifying supported input formats, and clarifying the return type (structured dictionary). It does not mention side effects, but as an analysis tool, the main non-obvious behavior (file accessibility) is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, supported formats, unsupported, args, returns) and front-loads the main purpose. While the Args section somewhat repeats the format details, the overall length is justified and each sentence adds value. The use of emojis and bullet points improves readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter and an output schema (not shown but noted), the description provides sufficient context: the purpose, input format restrictions, and return type. It does not detail the internal analysis contents, but the output schema is expected to cover that. The file access limitation is a critical contextual detail that is addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only declares pcap_file as a string with no description (coverage 0%). The description compensates by defining exactly what the parameter expects: an HTTP URL or absolute local file path, with examples. This gives the agent the necessary information to format the argument correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Analyze ICMP packets'), the resource ('from a PCAP file'), and the outcome ('return comprehensive analysis results'). It distinguishes itself from sibling tools like analyze_dns_packets and analyze_dhcp_packets by explicitly focusing on ICMP traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear setup guidance about file access (URL or local path) and unsupported upload methods, but it does not explicitly state when to use this tool over its siblings or when not to use it. Usage is implied through the name and protocol focus, but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_capinfosanalyze_dhcp_packetsanalyze_dns_packetsanalyze_icmp_packetsScored across 4 tools
Each tool targets a distinct protocol (DNS, DHCP, ICMP) or metadata (capinfos), with no overlap in purpose. An agent can easily select the correct tool based on the protocol of interest.
Three tools follow the clear 'analyze_<protocol>_packets' pattern, but 'analyze_capinfos' deviates by using a utility name instead of a protocol. The shared 'analyze_' prefix keeps the naming mostly predictable.
With 4 tools, the server is well-scoped for focused PCAP analysis. Each tool has a clear role and the count is appropriate for a niche protocol analyzer.
The set covers DNS, DHCP, and ICMP analysis plus metadata, but lacks support for other common protocols (e.g., TCP, UDP, ARP) and generic packet inspection. This creates notable gaps for general PCAP analysis, though the core three protocols are well-covered.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
