Skip to main content
Glama
mcpcap

mcpacket

by mcpcap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

mcpcap

A modular Python MCP (Model Context Protocol) server for analyzing PCAP files. mcpcap exposes protocol-specific analysis tools that accept a local file path or remote HTTP URL at call time, so the server stays stateless and works cleanly with MCP clients.

Overview

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.

Key Features

  • Stateless MCP Tools: Each analysis call supplies its own PCAP path or URL

  • Modular Architecture: DNS, DHCP, ICMP, TCP, SIP, and CapInfos modules with easy extensibility for new protocols

  • Advanced TCP Analysis: Connection lifecycle, traffic patterns, retransmissions, and flow inspection

  • 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: Wireshark-MCP

Installation

mcpcap requires Python 3.10 or greater.

Using pip

pip install mcpcap

Using uv

uv add mcpcap

Using uvx (for one-time usage)

uvx mcpcap

Using Docker

Build the image from the repository root:

docker build -t mcpcap .

Run it over HTTP for MCP clients that connect to a network endpoint:

docker run --rm \
  -p 8080:8080 \
  -v "$(pwd)/examples:/pcaps:ro" \
  mcpcap --transport http --host 0.0.0.0 --port 8080

Run it over stdio for clients that can spawn docker run directly:

docker run --rm -i \
  -v "$(pwd)/examples:/pcaps:ro" \
  mcpcap

When you mount local captures into the container, use the container path in tool calls:

analyze_dns_packets("/pcaps/dns.pcap")

Remote http:// and https:// PCAP URLs work without a volume mount because mcpcap downloads them inside the container at call time.

Using Docker Compose

For the default HTTP workflow, start the bundled Compose service:

docker compose up

This pulls ghcr.io/mcpcap/mcpcap:latest, publishes http://127.0.0.1:8080/mcp, and mounts ./examples into the container as /pcaps.

analyze_dns_packets("/pcaps/dns.pcap")

To analyze your own captures, change the volume in docker-compose.yml from ./examples:/pcaps:ro to your local capture directory.

For local development against the checked-out source instead of GHCR:

docker compose -f docker-compose.yml -f docker-compose.dev.yml up --build

Quick Start

1. Start the MCP Server

Start mcpcap as a stateless MCP server:

# Default stdio transport for Claude Desktop and similar clients
mcpcap

# Start with specific modules only
mcpcap --modules dns,tcp

# With packet analysis limits
mcpcap --max-packets 1000

# Start an HTTP transport server for remote MCP clients
mcpcap --transport http --host 127.0.0.1 --port 8080

2. Connect Your MCP Client

Use stdio transport for local MCP clients like Claude Desktop:

{
  "mcpServers": {
    "mcpcap": {
      "command": "mcpcap",
      "args": []
    }
  }
}

Use HTTP transport when your MCP client expects a network endpoint:

mcpcap --transport http --host 127.0.0.1 --port 8080

Point your HTTP-capable MCP client at:

http://127.0.0.1:8080/mcp

Docker users can publish the same endpoint with:

docker run --rm \
  -p 8080:8080 \
  -v "/path/to/captures:/pcaps:ro" \
  mcpcap --transport http --host 0.0.0.0 --port 8080

Or with Compose:

docker compose up

3. Analyze PCAP Files

Use the analysis tools with any PCAP file by providing the file path or URL when you call the tool:

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")

TCP Connection Analysis:

analyze_tcp_connections("/path/to/capture.pcap")
analyze_tcp_connections("/path/to/capture.pcap", server_ip="192.168.1.1", server_port=80)

TCP Pattern Analysis:

analyze_tcp_anomalies("/path/to/capture.pcap", server_ip="10.0.0.1")

TCP Retransmission Analysis:

analyze_tcp_retransmissions("/path/to/capture.pcap")

Traffic Flow Analysis:

analyze_traffic_flow("/path/to/capture.pcap", server_ip="192.168.1.100")

SIP Analysis:

analyze_sip_packets("/path/to/voip-signaling.pcap")
analyze_sip_packets("https://example.com/sip-call-flow.pcap")

CapInfos Analysis:

analyze_capinfos("/path/to/any.pcap")
analyze_capinfos("https://example.com/capture.pcap")

If you are using Docker with a bind mount, pass the in-container path instead of the host path:

analyze_capinfos("/pcaps/dns.pcap")

Available Tools

DNS Analysis Tools

  • 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

DHCP Analysis Tools

  • 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

ICMP Analysis Tools

  • 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

TCP Analysis Tools

  • analyze_tcp_connections(pcap_file, server_ip=None, server_port=None, detailed=False): TCP connection state analysis

    • Track TCP three-way handshake (SYN, SYN-ACK, ACK)

    • Analyze connection lifecycle and termination (FIN, RST)

    • Identify successful vs failed connections

    • Filter by server IP and/or port

    • Detect connection issues and abnormal closures

  • analyze_tcp_anomalies(pcap_file, server_ip=None, server_port=None): Observational TCP traffic analysis

    • Summarize handshakes, flags, resets, and retransmissions

    • Surface directional RST and retransmission patterns

    • Report connection lifecycle metrics

    • Return factual traffic patterns for further investigation

  • analyze_tcp_retransmissions(pcap_file, server_ip=None, threshold=0.02): TCP retransmission analysis

    • Measure overall and per-connection retransmission rates

    • Identify connections with quality issues

    • Compare against configurable thresholds

    • Detect network congestion and packet loss

  • analyze_traffic_flow(pcap_file, server_ip, server_port=None): Bidirectional traffic flow analysis

    • Analyze client-to-server vs server-to-client traffic

    • Identify traffic asymmetry

    • Determine RST packet sources

    • Interpret connection patterns and behaviors

SIP Analysis Tools

  • analyze_sip_packets(pcap_file): SIP signaling analysis

    • Parse SIP requests and responses across UDP and TCP transports

    • Extract call identifiers, CSeq values, endpoints, and key signaling headers

    • Summarize request methods and response code classes

    • Surface user agents, signaling servers, and transport usage

    • Support VoIP troubleshooting, security review, and forensic reconstruction

CapInfos Analysis Tools

  • 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

Analysis Prompts

mcpcap provides specialized analysis prompts to guide LLM analysis:

DNS Prompts

  • 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 Prompts

  • 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 Prompts

  • 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

TCP Prompts

  • tcp_connection_troubleshooting - Connection issues, handshake analysis, termination patterns

  • tcp_security_analysis - Attack detection, firewall analysis, anomaly identification

SIP Prompts

  • sip_security_analysis - Registration abuse, toll fraud, and signaling exposure review

  • sip_troubleshooting_analysis - Call setup progression, routing mismatches, and response-code failures

  • sip_forensic_investigation - Timeline reconstruction by Call-ID, CSeq, endpoint, and transport

Configuration Options

Module Selection

# Load specific modules
mcpcap --modules dns              # DNS analysis only
mcpcap --modules tcp              # TCP analysis only
mcpcap --modules dhcp             # DHCP analysis only
mcpcap --modules icmp             # ICMP analysis only
mcpcap --modules sip              # SIP analysis only
mcpcap --modules dns,tcp          # DNS and TCP analysis
mcpcap --modules dns,dhcp,icmp,tcp,sip,capinfos    # All modules (default)

Analysis Limits

# Limit packet analysis for large files
mcpcap --max-packets 1000

Transport Options

# Default stdio transport
mcpcap

# HTTP transport for network-accessible MCP clients
mcpcap --transport http

# HTTP transport on a custom interface and port
mcpcap --transport http --host 0.0.0.0 --port 9000

Complete Configuration Example

mcpcap --modules dns,dhcp,icmp,tcp,sip,capinfos --max-packets 500

CLI Reference

mcpcap [--modules MODULES] [--max-packets N] [--transport {stdio,http}] [--host HOST] [--port PORT]

Options:

  • --modules MODULES: Comma-separated modules to load (default: dns,dhcp,icmp,tcp,sip,capinfos)

    • Available modules: dns, dhcp, icmp, tcp, sip, capinfos

  • --max-packets N: Maximum packets to analyze per file (default: unlimited)

  • --transport {stdio,http}: MCP transport to expose (default: stdio)

  • --host HOST: Host to bind for HTTP transport (default: 127.0.0.1)

  • --port PORT: Port to bind for HTTP transport (default: 8080)

Examples:

# Start with all modules
mcpcap

# DNS and TCP analysis only
mcpcap --modules dns,tcp

# TCP analysis for troubleshooting connections
mcpcap --modules tcp

# With packet limits for large files
mcpcap --max-packets 1000

# Expose mcpcap over HTTP
mcpcap --transport http --host 127.0.0.1 --port 8080

Examples

Example PCAP files are included in the examples/ directory:

  • dns.pcap - DNS traffic for testing DNS analysis

  • dhcp.pcap - DHCP 4-way handshake capture

There is currently no bundled ICMP sample capture in examples/.

Using with MCP Inspector

npm install -g @modelcontextprotocol/inspector
npx @modelcontextprotocol/inspector mcpcap

Then test the tools:

// In the MCP Inspector web interface
analyze_dns_packets("./examples/dns.pcap")
analyze_dhcp_packets("./examples/dhcp.pcap")
analyze_capinfos("./examples/dns.pcap")
analyze_tcp_connections("/absolute/path/to/capture.pcap")
analyze_sip_packets("/absolute/path/to/voip-signaling.pcap")

Architecture

mcpcap's modular design supports easy extension:

Core Components

  1. BaseModule: Shared file handling, validation, and remote download

  2. Protocol Modules: DNS, DHCP, ICMP, TCP, SIP, and CapInfos implementations

  3. MCP Interface: Tool registration and prompt management

  4. FastMCP Framework: MCP server implementation

Tool Flow

MCP Client Request → analyze_*_packets(pcap_file)
                  → BaseModule.analyze_packets()
                  → Module._analyze_protocol_file()
                  → Structured JSON Response

Adding New Modules

Create new protocol modules by:

  1. Inheriting from BaseModule

  2. Implementing _analyze_protocol_file(pcap_file)

  3. Registering analysis tools with the MCP server

  4. Adding specialized analysis prompts

Future modules might include:

  • HTTP/HTTPS traffic analysis

  • UDP connection analysis

  • BGP routing analysis

  • SSL/TLS certificate analysis

  • Network forensics tools

  • Port scan detection

Remote File Support

Both analysis tools accept remote PCAP files via HTTP/HTTPS URLs:

# Examples of remote analysis
analyze_dns_packets("https://raw.githubusercontent.com/mcpcap/mcpcap/main/examples/dns.pcap")
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")
analyze_tcp_connections("https://example.com/tcp-session.pcap")
analyze_sip_packets("https://example.com/sip-signaling.pcap")

Features:

  • Automatic temporary download and cleanup

  • Support for .pcap, .pcapng, and .cap files

  • HTTP/HTTPS protocols supported

Security Considerations

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

Contributing

Contributions welcome! Areas for contribution:

  • New Protocol Modules: Add support for HTTP, BGP, TLS, RTP, etc.

  • Enhanced Analysis: Improve existing DNS/DHCP analysis

  • Security Features: Add more threat detection capabilities

  • Performance: Optimize analysis for large PCAP files

License

MIT

Requirements

  • Python 3.10+

  • scapy (packet parsing and analysis)

  • requests (remote file access)

  • fastmcp (MCP server framework)

Documentation

Support

For questions, issues, or feature requests, please open an issue on GitHub.

Available Tools

9 tools
analyze_capinfosA

Return metadata from a PCAP file, similar to Wireshark's capinfos utility.

IMPORTANT: This tool expects a FILE PATH or URL, not file content.

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)

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_packetsA

Analyze DHCP 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:

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

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description focuses on input constraints but does not disclose behavior such as whether the tool is read-only, destructive, or what the analysis results specifically contain beyond 'structured dictionary'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (limitation, supported/unsupported formats, args, returns). Could be slightly more concise, but each section adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and an output schema, the description covers input format thoroughly but lacks detail on the analysis output (e.g., what DHCP fields are analyzed). Output schema exists, but description could still provide a brief summary of return contents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'pcap_file' is described as 'HTTP URL or absolute local file path to PCAP file', adding significant meaning beyond the schema which only specifies type 'string'. Schema coverage is 0%, so description compensates fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it analyzes DHCP packets from a PCAP file and returns comprehensive analysis results. Differentiates from siblings which analyze other protocols (DNS, ICMP, SIP, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists supported input formats (URL, local path) and unsupported (Claude upload, base64, relative paths). Provides clear context for when to use, but does not compare directly to siblings beyond their names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_dns_packetsA

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:

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

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses file limitations and supported formats, and mentions return type. Lacks details on side effects, permissions, or performance, but covers key behavioral constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is verbose with sections (FILE UPLOAD LIMITATION, SUPPORTED, etc.) and docstring-style Args/Returns. While organized, it could be more concise without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers file input requirements and states 'comprehensive analysis results' but lacks detail on what DNS aspects are analyzed. Output schema exists but description could add more context about the analysis scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description fully compensates by explaining that pcap_file must be an HTTP URL or absolute local path, and explicitly lists unsupported formats (Claude uploads, base64, relative paths).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it analyzes DNS packets from a PCAP file and returns comprehensive results. The focus on DNS distinguishes it from siblings like analyze_dhcp_packets, analyze_icmp_packets, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit file input restrictions (local path or URL, not Claude upload or base64), giving clear when-to-use context. Does not explicitly contrast with siblings but sibling names imply specialization.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_icmp_packetsA

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:

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

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses file input limitations and return type, but lacks explicit mention that the tool is read-only or non-destructive, though it's implied. No annotations exist to contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, but slightly verbose; could trim redundant phrasing like 'comprehensive analysis results'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description adequately covers input constraints and purpose, making it complete for a single-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by detailing that pcap_file must be an HTTP URL or absolute local path, and what formats are unsupported.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Analyze ICMP packets from a PCAP file', using a specific verb and resource, and is easily distinguishable from sibling tools that analyze other protocols like DHCP, DNS, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists supported and unsupported input formats, including a warning about Claude's file upload limitation, guiding the agent on when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_sip_packetsA

Analyze SIP packets from a PCAP file and return structured signaling details.

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:

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 SIP packet analysis results

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses file upload limitations, supported formats, and return type. Could mention error behavior (e.g., invalid file) but overall sufficient for a read-only analysis tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections and examples. Slightly verbose but every sentence adds value. Could condense the file upload limitation into one concise statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Single parameter, no annotations, but description covers purpose, input restrictions, and return type. It is complete and actionable for a tool with this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% parameter description coverage, so description must compensate. It specifies 'HTTP URL or absolute local file path' and provides examples, adding critical meaning beyond the raw schema type 'string'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool analyzes SIP packets from a PCAP file and returns structured signaling details. The verb 'analyze' and resource 'SIP packets from a PCAP file' are specific and distinct from siblings (e.g., analyze_dns_packets, analyze_tcp_connections).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when-to-use guidance: supports remote URLs and absolute local paths. Also specifies unsupported inputs (Claude upload, base64, relative paths) and a key limitation. This helps the agent avoid common errors.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_tcp_anomaliesA

Detect TCP traffic patterns through statistical analysis.

This tool analyzes TCP traffic to identify observable patterns without making assumptions about root causes. It provides factual metrics and pattern detection that can be used for further investigation.

Args: pcap_file: HTTP URL or absolute local file path to PCAP file server_ip: Optional filter for server IP address server_port: Optional filter for server port

Returns: A structured dictionary containing: - statistics: Comprehensive TCP metrics (handshakes, flags, RST distribution, etc.) - patterns: Observable patterns detected in the traffic - summary: High-level summary of findings

Detected pattern categories:

  • connection_establishment: Handshake success/failure rates, SYN response ratios

  • connection_termination: RST distribution, normal vs abnormal closes

  • reliability: Retransmission rates, packet loss indicators

  • connection_lifecycle: Connection state transitions

The analysis is purely observational - it reports what is seen in the traffic without attempting to diagnose specific issues like "firewall block" or "network congestion". This allows the data to be interpreted in context.

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes
server_ipNo
server_portNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clearly explains the tool is purely observational, reports factual metrics, and does not attempt to diagnose. It covers its non-destructive nature and scope, though it could explicitly state it is read-only or safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for args, returns, and pattern categories. It is slightly verbose but each sentence adds value. It front-loads the main purpose and is easy to parse, though a bit longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It describes return values comprehensively, covering statistics, patterns, and summary, and lists pattern categories. However, it omits error conditions or prerequisites for the pcap_file (e.g., accessibility). Given the presence of an output schema, the description fills gaps well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description fully compensates by explaining each parameter: pcap_file (HTTP URL or absolute local file path), server_ip and server_port (optional filters). This adds valuable meaning beyond the schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it detects TCP traffic patterns through statistical analysis and lists specific pattern categories. It differentiates itself by emphasizing observational analysis without diagnosing root causes, but does not explicitly distinguish from sibling tools like analyze_tcp_connections or analyze_tcp_retransmissions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for observational pattern detection and advises against using it for diagnosis, but it does not explicitly state when to prefer this tool over siblings or provide exclusions. Better guidance on alternatives would improve it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_tcp_connectionsA

Analyze TCP connection states and lifecycle.

This is the core tool for TCP connection analysis, solving 80% of TCP-related issues.

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:

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 server_ip: Optional filter for server IP address server_port: Optional filter for server port detailed: Whether to return detailed connection information

Returns: A structured dictionary containing TCP connection analysis results including: - summary: Overall connection statistics - connections: List of individual connections with states - issues: Detected problems

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes
server_ipNo
server_portNo
detailedNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It does cover important constraints (file upload limitation, supported input formats) and hints at read-only analysis. However, it doesn't explicitly state that the tool performs no mutations or confirm that it only reads data. The description is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise given the amount of context provided. It front-loads the primary purpose and then covers limitations, input formats, and parameters. Some details (like the file upload limitation) could be more prominent, but overall structure is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and a moderate number of parameters (4), the description provides enough information to select and use the tool. It explains input formats, optional filters, and return structure. However, it lacks guidance on when not to use this tool, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning to parameters. The 'Args' section explains each parameter's purpose and type beyond the basic schema: pcap_file (URL or path), server_ip/port (filters), detailed (returns detailed info). This adds significant value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: analyzing TCP connection states and lifecycle. It positions itself as the core tool for TCP issues, distinguishing from siblings like 'analyze_tcp_anomalies' and 'analyze_tcp_retransmissions' by claiming to solve 80% of TCP-related problems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it labels itself as the 'core tool', it does not explicitly guide when to use this tool versus siblings. For example, it doesn't say 'use analyze_tcp_anomalies for unusual patterns' or 'use analyze_tcp_retransmissions for retransmission-specific debugging'. The description implies broad use but lacks exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_tcp_retransmissionsA

Analyze TCP retransmission patterns.

Args: pcap_file: HTTP URL or absolute local file path to PCAP file server_ip: Optional filter for server IP address threshold: Retransmission rate threshold (default: 2%)

Returns: A structured dictionary containing: - total_retransmissions: Total number of retransmissions - retransmission_rate: Overall retransmission rate - by_connection: Per-connection retransmission statistics - summary: Worst connections and threshold violations

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes
server_ipNo
thresholdNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that pcap_file can be an HTTP URL or local file, implying network fetching capability. However, it does not mention side effects, permissions, file size limits, or if the tool modifies any data. The behavioral transparency is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a single-line summary, followed by Args in a bullet-like list, and Returns in a structured list. Every sentence adds value, and the essential information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (described in Returns) and the moderate complexity (3 parameters), the description covers all necessary information. It could be enhanced by discussing performance or interpretation, but it is largely complete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 0%, so the description adds all parameter meaning. It clearly explains each parameter: pcap_file (URL or local path), server_ip (optional filter), and threshold (with default 2%). This is a significant addition over the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Analyze TCP retransmission patterns', which is a specific verb+resource. It distinguishes from sibling tools like analyze_tcp_anomalies and analyze_tcp_connections by focusing on retransmissions, though it could be more explicit about the unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives (e.g., analyze_tcp_anomalies or analyze_tcp_connections). The description does not include when-to-use, when-not-to-use, or mention any prerequisites, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_traffic_flowA

Analyze bidirectional traffic flow characteristics.

Identifies traffic direction, asymmetry, RST sources, and data transfer patterns.

Args: pcap_file: HTTP URL or absolute local file path to PCAP file server_ip: Server IP address (required) server_port: Optional filter for server port

Returns: A structured dictionary containing: - client_to_server: Client-to-server traffic statistics - server_to_client: Server-to-client traffic statistics - analysis: Asymmetry analysis and interpretations

ParametersJSON Schema
NameRequiredDescriptionDefault
pcap_fileYes
server_ipYes
server_portNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It states the tool 'Analyzes' and returns results, but does not mention whether it modifies any state, requires special permissions, or has rate limits. As a read-only analysis tool, safety is implied but not explicit. This lack of transparency could leave an agent uncertain about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear one-line summary followed by structured args and returns sections. It avoids unnecessary detail but is slightly repetitive with the schema (e.g., required field mentioned). Overall, it is efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters and a detailed output schema, the description is complete: it explains input semantics and output structure (structured dictionary with specific fields). The presence of a described return object compensates for the lack of an explicit output schema. No additional context is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully explains each parameter: pcap_file is 'HTTP URL or absolute local file path', server_ip is 'Server IP address (required)', server_port is 'Optional filter for server port'. This adds essential meaning beyond the schema's type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze bidirectional traffic flow characteristics' and lists specific outputs (traffic direction, asymmetry, RST sources, data transfer patterns). It is distinct from sibling tools like analyze_dns_packets or analyze_tcp_connections, focusing on overall flow rather than specific protocols or anomalies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It implies usage for general traffic flow analysis, but lacks guidance on exclusions or scenarios where siblings (e.g., analyze_tcp_retransmissions) would be more appropriate. The context is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.9.6
    • Addedanalyze_sip_packets
  2. 8 tool updatesv1.0.0
    • Changedanalyze_capinfos1 field changed
      • removedInput schema / properties / pcap_file / title
        Removed value: -"Pcap File"
    • Changedanalyze_dhcp_packets1 field changed
      • removedInput schema / properties / pcap_file / title
        Removed value: -"Pcap File"
    • Changedanalyze_dns_packets1 field changed
      • removedInput schema / properties / pcap_file / title
        Removed value: -"Pcap File"
    • Changedanalyze_icmp_packets1 field changed
      • removedInput schema / properties / pcap_file / title
        Removed value: -"Pcap File"
    • Addedanalyze_tcp_anomalies
    • Addedanalyze_tcp_connections
    • Addedanalyze_tcp_retransmissions
    • Addedanalyze_traffic_flow
  3. 4 tool updates
    • First observedanalyze_capinfos
    • First observedanalyze_dhcp_packets
    • First observedanalyze_dns_packets
    • First observedanalyze_icmp_packets
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 9 tools

Disambiguation4/5

Most tools target distinct protocols or aspects (e.g., DHCP, DNS, ICMP, SIP, TCP connections, retransmissions). The three TCP-focused tools have overlapping domains but are differentiated by their focus (state vs. anomalies vs. retransmissions). Descriptions are clear enough to avoid confusion.

Naming Consistency5/5

All tools follow a consistent 'analyze_<protocol_or_feature>' pattern using snake_case (e.g., analyze_dns_packets, analyze_tcp_connections). No deviations or mixed conventions.

Tool Count5/5

9 tools is appropriate for a PCAP analysis server. It covers general metadata, several important protocols, and detailed TCP analysis without being excessive or too sparse.

Completeness3/5

The tool set covers common network scenarios but lacks support for many other protocols (e.g., HTTP, ARP, UDP general, TLS). Notable gaps exist for a general-purpose packet analyzer, though the focus on TCP and specific protocols is reasonable.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Wireshark MCP

    bx33661
    A
    license
    B
    quality
    A
    maintenance
    An MCP server that enables LLMs to analyze pcap files by providing tools for packet dissection, stream following, and data extraction via tshark. It supports protocol hierarchy analysis, credential scanning, and threat intelligence checks on captured network traffic.
    52
    470 PyPI
    238
    MIT

  • Wireshark MCP

    andsopwn
    F
    license
    C
    quality
    D
    maintenance
    Enables LLMs to capture, analyze, and summarize network traffic using Wireshark CLI tools, supporting live capture, pcap analysis, and LLM-oriented summaries.
    76
    -

  • mcpcap

    sentry-official
    A
    license
    A
    quality
    D
    maintenance
    A modular MCP server for analyzing PCAP files using protocol-specific analysis tools, enabling LLMs to read and analyze network packet captures from local paths or remote URLs.
    4
    MIT