Provides network packet analysis capabilities via Wireshark/tshark, including live packet capture, PCAP analysis, protocol statistics, stream reconstruction, file extraction, credential extraction, and HTTP object export.
Click on "Install 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., "@Wireshark MCP Server analyze the pcap file for DNS queries"
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 Model Context Protocol (MCP) server that provides network packet analysis capabilities via Wireshark/tshark on a remote machine (e.g., Kali Linux).
This server enables AI assistants to perform sophisticated network traffic analysis, packet capture, protocol inspection, and security-focused operations through a standardized MCP interface.
Live Packet Capture - Capture network traffic on remote interfaces with BPF filters
PCAP Analysis - Read and analyze existing pcap files
Protocol Statistics - Generate protocol hierarchy, conversations, endpoints, and I/O statistics
Stream Reconstruction - Follow TCP, UDP, HTTP, and TLS streams
File Extraction - Extract files from HTTP, SMB, DICOM, IMF, and TFTP traffic
Deep Packet Inspection - Decode packets with full protocol details
Credential Extraction - Search for credentials in HTTP Basic Auth, FTP, Telnet, and form submissions
HTTP Object Export - List and export HTTP objects from captures
Related MCP server: Wireshark MCP
Node.js 18+
SSH access to a remote machine with tshark installed (e.g., Kali Linux)
SSH key-based authentication configured (password-less)
sudo access on the remote machine for packet capture
git clone https://github.com/schwarztim/sec-wireshark-mcp.git
cd sec-wireshark-mcp
npm install
npm run buildSet the following environment variables:
Variable | Description | Default |
| SSH hostname or IP of the remote machine |
|
| SSH username (optional if using SSH config) | (empty) |
| Directory on remote host for pcap files |
|
export WIRESHARK_SSH_HOST="192.168.1.100"
export WIRESHARK_SSH_USER="kali"Or use an SSH config entry:
# ~/.ssh/config
Host kali
HostName 192.168.1.100
User kali
IdentityFile ~/.ssh/id_rsaAdd to your Claude Desktop configuration (~/.claude/user-mcps.json or Claude Desktop settings):
{
"mcpServers": {
"wireshark": {
"command": "node",
"args": ["/path/to/sec-wireshark-mcp/dist/index.js"],
"env": {
"WIRESHARK_SSH_HOST": "kali",
"WIRESHARK_SSH_USER": "kali"
}
}
}
}tshark_list_interfacesList available network interfaces on the remote machine for packet capture.
tshark_captureStart packet capture on a specified interface.
Parameters:
interface (required): Network interface (e.g., eth0, wlan0)
count: Number of packets to capture (default: 10, max: 1000)
filter: BPF capture filter (e.g., port 80, host 192.168.1.1)
timeout: Capture timeout in seconds (default: 10, max: 60)
outputFile: Save capture to pcap file on remote host
tshark_read_pcapRead and analyze a pcap file.
Parameters:
file (required): Path to the pcap file on remote host
filter: Wireshark display filter
count: Maximum packets to return (default: 100, max: 1000)
fields: Specific fields to extract (e.g., ['ip.src', 'ip.dst', 'tcp.port'])
tshark_filterApply a display filter to a pcap file.
Parameters:
file (required): Path to the pcap file
filter (required): Display filter (e.g., http.request, dns, tcp.flags.syn == 1)
outputFormat: json, text, or fields (default: json)
fields: Fields to extract when using fields format
tshark_statsGenerate protocol statistics from a pcap file.
Parameters:
file (required): Path to the pcap file
type (required): hierarchy, conversations, endpoints, io, http, or dns
protocol: Protocol for conversations/endpoints (e.g., tcp, udp, ip)
tshark_follow_streamReconstruct a TCP, UDP, HTTP, or TLS stream.
Parameters:
file (required): Path to the pcap file
protocol (required): tcp, udp, http, or tls
streamIndex: Stream index number (default: 0)
format: ascii, hex, or raw (default: ascii)
tshark_extract_filesExtract files from protocol traffic.
Parameters:
file (required): Path to the pcap file
protocol: http, dicom, imf, smb, or tftp (default: http)
outputDir: Directory for extracted files (default: /tmp/mcp-extracted)
tshark_decodeDeep packet inspection with full protocol details.
Parameters:
file (required): Path to the pcap file
packetNumber: Specific packet number to decode
filter: Display filter to select packets
protocols: Specific protocols to show (e.g., ['http', 'tcp', 'ip'])
verbose: Show all protocol details (default: false)
tshark_extract_credentialsSearch for potential credentials in network traffic.
Parameters:
file (required): Path to the pcap file
Searches for HTTP Basic Auth, FTP credentials, HTTP POST form data, and Telnet data.
tshark_export_objectsList and export HTTP objects from a capture.
Parameters:
file (required): Path to the pcap file
listOnly: Only list objects without extracting (default: true)
outputDir: Directory for extracted objects
This server executes commands on a remote machine via SSH
Input sanitization is implemented to prevent command injection
Use SSH key authentication with appropriate permissions
Consider network segmentation for the capture machine
The remote machine requires sudo access for live capture
Credential extraction features should be used only for authorized security testing
# Run in development mode
npm run dev
# Build for production
npm run build
# Start production server
npm startMIT License - see LICENSE for details.
Contributions are welcome! Please feel free to submit a Pull Request.
Model Context Protocol - The protocol specification
Wireshark - Network protocol analyzer
tshark - Terminal-based Wireshark
Start packet capture on the remote Kali machine. Returns captured packets in JSON format. Requires sudo on the remote host.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of packets to capture (default: 10, max: 1000) | |
| filter | No | Capture filter (BPF syntax, e.g., 'port 80', 'host 192.168.1.1') | |
| timeout | No | Capture timeout in seconds (default: 10, max: 60) | |
| interface | Yes | Network interface to capture on (e.g., eth0, wlan0) | |
| outputFile | No | Optional: Save capture to pcap file on remote host |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially fills the gap by noting the result format (JSON) and the sudo requirement. However, it does not disclose default behaviors, error states, or potential side effects like network disruption.
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 extremely concise, containing two sentences that front-load the core action and add the critical sudo requirement. Every word serves a purpose with no redundancy.
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 5 parameters and no output schema, the description covers the essential purpose and a key prerequisite (sudo), but it lacks details on output format specifics, error scenarios, and usage context compared to siblings. It is minimally adequate.
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 already has 100% coverage with descriptions for all parameters. The description adds no extra parameter-level meaning beyond what the schema provides, meeting the baseline.
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 starts a packet capture on a remote Kali machine and returns JSON. The name 'capture' distinguishes it from siblings like 'read_pcap' and 'filter', but no explicit differentiation is provided.
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 only mentions a prerequisite (sudo) but provides no guidance on when to use this tool versus alternatives like `tshark_read_pcap` or `tshark_filter`. No when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode specific packets with detailed protocol information. Useful for deep packet inspection.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| filter | No | Display filter to select packets (optional) | |
| verbose | No | Show all protocol details (default: false) | |
| protocols | No | Specific protocols to show details for (e.g., ['http', 'tcp', 'ip']) | |
| packetNumber | No | Specific packet number to decode (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as permissions needed, side effects, error handling (e.g., if packet not found), or output format. The description is minimal.
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 very concise with two short sentences. It avoids redundancy, though it could be slightly more informative without losing conciseness.
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?
No output schema is provided, and the description does not explain what the tool returns (e.g., decoded packet details in what format). For a decoding tool with 5 parameters, this is incomplete.
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 description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
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 decodes specific packets with detailed protocol information, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like tshark_read_pcap, which may also decode packets.
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 only says 'useful for deep packet inspection,' which implies usage but provides no explicit guidance on when to use this tool versus alternatives. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and export HTTP objects (files) from a pcap capture
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| listOnly | No | Only list objects without extracting (default: true) | |
| outputDir | No | Directory to save extracted objects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior of listing and exporting HTTP objects, implying file creation via outputDir parameter. However, it lacks details on side effects, permissions, or whether the pcap is modified. With no annotations, more behavioral context would be beneficial.
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?
Single sentence, front-loaded, and contains no extraneous information. Every word is informative.
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?
The description does not explain what the output looks like (e.g., list format, returned object paths) or how extraction results are returned. With no output schema, this information is missing, leaving the agent guessing about the tool's return value.
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 100%, so the schema already describes all parameters. The description adds no extra semantic meaning beyond stating the overall purpose. Baseline score of 3 is appropriate.
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 lists and exports HTTP objects from pcap files. While specific to HTTP objects, it does not differentiate from sibling tool 'tshark_extract_files', which may have overlapping functionality.
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?
No guidance is provided on when to use this tool versus alternatives like tshark_extract_files or other tshark tools. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for potential credentials in network traffic (HTTP Basic Auth, FTP, Telnet, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only says 'search' but does not disclose whether results are displayed, saved, or if any data is modified. No safety or permission hints.
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?
Single sentence, concise, front-loaded with purpose. No extraneous 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?
For a simple tool with one parameter and no output schema, the description is adequate but lacks behavioral detail that would make it fully complete for an AI agent.
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 100% and already describes the 'file' parameter. The description adds no extra meaning beyond the schema, meeting the baseline.
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 purpose: 'Search for potential credentials in network traffic' with specific examples of protocols (HTTP Basic Auth, FTP, Telnet). This is distinct from sibling tools like tshark_filter or tshark_follow_stream.
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or which sibling tools might be better suited for different credential extraction scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract files from HTTP, DICOM, IMF, SMB, or TFTP traffic in a pcap file.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| protocol | No | Protocol to extract files from (default: http) | |
| outputDir | No | Directory to save extracted files (default: /tmp/mcp-extracted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It does not disclose that extraction likely writes files to disk, whether the pcap is modified, or any authorization/rate limit concerns. The behavioral details are minimal.
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 a single sentence with no wasted words. It is front-loaded with the verb and key resources, making it efficient and easy to scan.
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 complexity of file extraction across multiple protocols, the description leaves out important context such as the default protocol (http), default output directory (/tmp/mcp-extracted), and behavior when files already exist. No output schema is provided, increasing the need for description completeness.
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 100% with all parameters described. The description adds the list of protocols (which matches the enum) but no additional meaning beyond the schema for 'file' or 'outputDir'. Baseline 3 is appropriate.
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 uses the specific verb 'extract' and resources 'files from HTTP, DICOM, IMF, SMB, or TFTP traffic' and the pcap file context. It clearly states what the tool does but does not differentiate from sibling tools like tshark_export_objects or tshark_extract_credentials, though the name and purpose are distinct enough.
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 only states what the tool does, with no guidance on when to use it versus alternatives like tshark_export_objects or tshark_follow_stream. No prerequisites 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.
Apply a display filter to a pcap file and return matching packets. Useful for extracting specific traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| fields | No | Fields to extract when outputFormat is 'fields' | |
| filter | Yes | Display filter (e.g., 'http.request', 'dns', 'tcp.flags.syn == 1') | |
| outputFormat | No | Output format (default: json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency responsibility but only states basic operation. It does not disclose performance implications, file requirements (beyond parameter descriptions), or error behavior, leaving significant gaps for an agent to assess 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with two sentences, no redundant phrases, and the primary action is front-loaded. Every sentence contributes to understanding the core function without excess.
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?
The description omits context about output format options, field extraction behavior, and handling of large files. Given the absence of an output schema and the presence of multiple parameters, this is insufficient for an agent to fully understand what the tool returns or edge cases.
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?
Since schema coverage is 100% and each parameter has a description, the tool description adds no additional meaning beyond what the schema provides. The baseline of 3 is appropriate as the description does not compensate for any missing parameter context.
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 applies a display filter to a pcap file and returns matching packets, specifying its purpose and utility. It distinguishes from siblings like tshark_stats (statistics) and tshark_capture (capturing), but could more explicitly differentiate from tshark_read_pcap or tshark_follow_stream.
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 only a vague phrase 'Useful for extracting specific traffic' without clear guidance on when to use this tool versus alternatives like tshark_follow_stream or tshark_stats. No prerequisites, exclusions, or when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow and reconstruct a TCP, UDP, or HTTP stream from a pcap file. Shows the full conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| format | No | Output format (default: ascii) | |
| protocol | Yes | Protocol stream to follow | |
| streamIndex | No | Stream index number (default: 0 for first stream) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'Shows the full conversation' without explaining output format, side effects, or limitations (e.g., only one stream at a time). It does not mention that the tool reconstructs the stream by reassembling packets, nor does it discuss permissions or resource usage. The minimal description leaves significant gaps.
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 two sentences and 15 words – highly concise. Every word is informative and there is no redundancy. It front-loads the main purpose immediately.
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 no output schema and no annotations, the description is moderately complete. It tells the core function but omits details like what the output looks like (e.g., plaintext conversation) and how to handle multiple streams. There's a minor inconsistency: the description lists HTTP but the schema includes TLS as a protocol option. This gap reduces completeness for a tool with four parameters and no output schema.
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 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. For example, it does not clarify the difference between format options ('ascii', 'hex', 'raw') or how streamIndex works. The schema already provides enum values and descriptions, so the description is not required to add more, but it does not compensate for any ambiguity.
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 core function: 'Follow and reconstruct a TCP, UDP, or HTTP stream from a pcap file. Shows the full conversation.' It uses specific verbs and resources, and distinguishes from sibling tools like tshark_filter (which filters packets) and tshark_read_pcap (which reads raw packets).
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 implies usage after capturing a pcap file but provides no explicit guidance on when to use this tool versus alternatives like tshark_filter or tshark_stats. It does not mention prerequisites, limitations, or when not to use it. The context is clear but lacks exclusions or directed advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available network interfaces on the remote Kali machine for packet capture
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states listing interfaces, which is non-destructive, but does not clarify permissions, limitations, or scope of 'available'. Adequate but not rich.
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?
Single concise sentence, front-loaded with key information, no extraneous text.
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 parameterless list tool, the description fully captures what the tool does. No output schema is expected; the tool name and sibling context provide further clarity.
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?
No parameters exist, so baseline 4 applies. The description does not need to add parameter meaning.
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 lists available network interfaces for packet capture, with a specific resource (network interfaces) and action (list), distinguishing it from sibling tools like tshark_capture or tshark_filter.
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?
Usage is implied as a preliminary step before capture, but no explicit guidance on when to use or alternatives is provided. The context of sibling tools helps, but the description itself lacks this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and analyze a pcap file from the remote Kali machine. Returns packets in JSON format.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| count | No | Maximum number of packets to return (default: 100, max: 1000) | |
| fields | No | Specific fields to extract (e.g., ['ip.src', 'ip.dst', 'tcp.port']) | |
| filter | No | Display filter to apply (Wireshark syntax, e.g., 'http', 'tcp.port == 443') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the responsibility for disclosing behavioral traits. It only states 'read and analyze' without clarifying if the tool is read-only, what happens on error, or any side effects (e.g., resource usage). The phrase 'analyze' is vague and does not specify any transformations or processing beyond extraction.
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 very concise: two sentences that immediately convey the core action and output. There is no fluff or unnecessary detail.
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 has 4 parameters and no output schema, the description is too brief. It does not explain what 'analyze' entails, how the JSON output is structured, or any limitations (e.g., file size). For a complex tool like pcap analysis, more detail is needed for adequate completeness.
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 has 100% description coverage, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides. For example, it doesn't mention that 'file' is required or that 'count' has a default and maximum.
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 action (read and analyze a pcap file), the context (remote Kali machine), and the output format (JSON). It effectively distinguishes from sibling tools like tshark_capture (which captures live traffic) and tshark_filter (which filters already captured data).
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?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, when not to use it, or any prerequisites. For instance, it doesn't note that the pcap file must exist or that tshark should be installed on the remote host.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get protocol statistics from a pcap file. Shows protocol hierarchy, conversations, and endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Path to the pcap file on the remote host | |
| type | Yes | Type of statistics to generate | |
| protocol | No | Protocol for conversations/endpoints (e.g., 'tcp', 'udp', 'ip') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It does not mention that the tool is read-only, nor does it describe potential performance impacts with large files or error conditions. The description lacks transparency for a safe and effective invocation.
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 short (two sentences) and to the point, but could be more structured (e.g., listing all supported types). It is concise but not optimally informative; adding the full enum list would improve clarity without much verbosity.
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?
The tool has 3 parameters (2 required) and no output schema. The description does not explain the output format or return structure, nor does it address error handling or file size considerations. Given the complexity and lack of annotations, the description is incomplete for an agent to fully understand invocation consequences.
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 high (100%), so baseline is 3, but the description's list of types ('hierarchy, conversations, and endpoints') contradicts the schema's full enum which also includes 'io', 'http', 'dns'. This omission could mislead the agent into thinking only those three types are available, reducing parameter understanding.
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?
Description clearly states the tool retrieves protocol statistics from pcap files and lists three output types (hierarchy, conversations, endpoints). This distinguishes it from siblings like tshark_filter (filtering) and tshark_decode (decoding). However, the description omits 'io', 'http', and 'dns' types that exist in the schema, making it slightly incomplete but still clear.
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?
No explicit guidance on when to use this tool versus alternatives like tshark_read_pcap or tshark_filter. No prerequisites or context for selecting the 'type' parameter are provided. The description simply states what it does without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, covering different aspects of packet analysis: capture, read, filter, decode, export objects, extract credentials, follow streams, list interfaces, and statistics. No overlap in functionality.
All tools follow a consistent 'tshark_' prefix with lowercase and underscores. Verbs are well-chosen and predictable (e.g., capture, decode, filter, follow_stream), making the surface easy to navigate.
With 10 tools, the server is well-scoped for the domain of network packet analysis. It provides a focused set without being overwhelming or too sparse.
The tool set covers key workflows: capture, read, filter, decode, extract objects/credentials, and statistics. Minor gaps exist (e.g., no tool to stop capture or merge pcaps), but the core functionality is well-represented.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-wireshark-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server