The otparse-mcp server parses OT/ICS packet captures (PCAPs) and returns structured JSON for analysis in LLM workflows. Key capabilities:
Parse Modbus/TCP traffic (parse_modbus_pcap): Extracts and decodes Modbus/TCP transactions from a PCAP file, returning decoded frames and a device inventory derived from observed IP addresses.
Parse BACnet/IP traffic (parse_bacnet_pcap): Extracts and decodes BACnet/IP packets from a PCAP file, returning decoded packets and a device inventory (including BACnet device instance numbers/object names when available).
Control analysis scope: Both tools accept an optional packet_limit parameter (default: 500) to cap packets processed per run.
Structured JSON output: Results are designed for direct LLM reasoning, enabling natural language analysis of industrial network activity from saved PCAP evidence.
Containerized execution: Runs in Docker with read-only evidence mounts and no network access.
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., "@otparse-mcp Analyze /evidence/modbus/traffic.pcap and show me the device inventory."
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 containerized MCP server that parses OT/ICS packet captures and returns structured JSON. Designed to plug into a Claude Code workflow for analyzing saved PCAP files from Modbus/TCP and BACnet/IP networks.
Status: [EXPERIMENTAL]
otparse exposes two MCP tools:
parse_modbus_pcap -- reads a saved PCAP file, extracts Modbus/TCP transactions using tshark, and returns decoded frames plus a basic device inventory derived from observed IPs.
parse_bacnet_pcap -- reads a saved PCAP file, extracts BACnet/IP packets using tshark, and returns decoded frames plus a basic device inventory derived from observed IPs.
Both tools accept a path to a PCAP inside the container and an optional packet limit. Output is structured JSON that an LLM can reason over directly.
Related MCP server: TShark2MCP
This grew out of interest in OT/ICS security and the gap between "I have a PCAP from an industrial network" and "I can actually understand what devices were talking to each other and whether anything looks off." Wrapping tshark in an MCP server means Claude can do the first layer of that analysis without a separate toolchain.
The container design follows the same pattern as netparse: read-only evidence mount, no outbound network access, non-root user.
Docker (for the containerized path)
Or: Python 3.11+, tshark installed on the host (for local dev)
docker build -t otparse-mcp .python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pip install -e .tshark must be available in your PATH for local development.
docker run --rm -i \
--network none \
-v /srv/evidence:/evidence:ro \
otparse-mcp:latest{
"mcpServers": {
"otparse": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"--network", "none",
"-v", "/srv/evidence:/evidence:ro",
"otparse-mcp:latest"
]
}
}
}Once connected, ask Claude something like:
"Parse the Modbus capture at
/evidence/modbus/example.pcapand summarize what devices were communicating."
Claude will call parse_modbus_pcap and work from the returned JSON.
python -m otparse.serverotparse/
├── otparse/
│ ├── __init__.py
│ ├── server.py # FastMCP server, tool definitions
│ ├── models.py # Pydantic models for all inputs/outputs
│ ├── parsers/
│ │ ├── common.py # Shared helpers (path validation, tshark check, type coercion)
│ │ ├── modbus.py # Modbus/TCP parser using pyshark + tshark
│ │ └── bacnet.py # BACnet/IP parser using pyshark + tshark
│ └── analyzers/
│ └── devices.py # Builds device inventory from parsed transactions
├── Dockerfile
├── docker-compose.yml
├── pyproject.toml
├── requirements.txt
└── README.mdSee docs/tool-reference.md for full parameter and output documentation.
This tool only analyzes saved PCAP files. It does not do live capture.
tshark does the actual protocol dissection. If a PCAP uses a non-standard port or an unusual encapsulation, tshark may not identify the traffic and the tool will return an empty result with a note.
Modbus direction (request vs. response) detection depends on pyshark exposing the right attributes. Some captures may produce "unknown" for most frames.
The device inventory is derived purely from observed source/destination IPs. It does not correlate with vendor OUIs, DHCP records, or any external data source.
BACnet device instance numbers and object names are extracted when present, but tshark attribute names vary by version. Some fields may be null on older tshark builds.
docker-compose.yml is included for convenience but assumes the repo root layout matches the build context. Adjust build: paths if your layout differs.
Both tools accept an optional packet_limit parameter (default: 500) that caps the number of matching packets decoded per run. This limit is in place during early testing and will be removed in a future version. For large captures, increase the limit explicitly when calling the tool.
Sample ICS PCAPs suitable for testing can be found in the ITI ICS-Security-Tools repository, which maintains a collection of ICS protocol captures for security research.
extract_ics_devices tool combining Modbus and BACnet inventory into a single view
Anomaly heuristics (unusual function codes, broadcast storms, write-heavy sessions)
Timeline/session summarizer tool
Fixture PCAPs and parser unit tests
See CHANGELOG.md
Parse BACnet/IP traffic from a PCAP and return decoded packets plus a basic device inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | ||
| packet_limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns decoded packets and a basic device inventory, which gives some output context, but it doesn't cover critical behavioral aspects like performance characteristics, error handling, memory usage, or whether the operation is read-only or has side effects. For a tool processing network data with no annotation coverage, this is insufficient.
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, well-structured sentence that efficiently conveys the core functionality without unnecessary details. It's front-loaded with the main action and result, making it easy to understand at a glance. Every word earns its place, with no redundancy or fluff.
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 complexity (parsing network traffic), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the format of decoded packets, what constitutes a 'basic device inventory', potential limitations, or how errors are handled. For a data processing tool with no structured output information, more context is needed to be fully helpful.
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 description adds no parameter semantics beyond what the input schema provides. With 0% schema description coverage, the schema only lists parameter names and types without descriptions. The description doesn't explain what 'pcap_path' or 'packet_limit' mean, their formats, or constraints. However, since there are only 2 parameters and the tool's purpose is straightforward, a baseline score of 3 is appropriate as the description doesn't actively mislead but fails to compensate for the schema gap.
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: parsing BACnet/IP traffic from a PCAP file to return decoded packets and a basic device inventory. It specifies both the verb ('parse') and resource ('BACnet/IP traffic from a PCAP'), though it doesn't explicitly differentiate from its sibling parse_modbus_pcap beyond the protocol name. This is clear but lacks explicit sibling differentiation.
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 no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool parse_modbus_pcap, nor does it specify prerequisites, constraints, or typical use cases. Usage is implied by the protocol name (BACnet/IP), but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse Modbus/TCP traffic from a PCAP and return transactions plus a basic device inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| pcap_path | Yes | ||
| packet_limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions parsing and returning data, but does not describe error handling, performance characteristics (e.g., time/memory usage for large PCAPs), or any limitations (e.g., supported Modbus/TCP versions). This leaves significant gaps for a tool that processes network data.
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, well-structured sentence that efficiently conveys the tool's purpose and outputs without unnecessary details. It is front-loaded and every word contributes to understanding the tool's function.
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 parsing network traffic, no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks details on output format (e.g., structure of transactions/inventory), error cases, and behavioral constraints, making it inadequate for informed tool selection.
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 description does not add meaning beyond the input schema, which has 0% description coverage. It mentions 'PCAP' and 'packet limit' implicitly, but provides no details on parameter formats (e.g., file path requirements, valid ranges for packet_limit). With low schema coverage, the description does not adequately compensate, resulting in a baseline score.
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 specific action ('Parse Modbus/TCP traffic from a PCAP') and the resources involved ('PCAP'), with explicit outputs ('return transactions plus a basic device inventory'). It distinguishes from the sibling tool 'parse_bacnet_pcap' by specifying the protocol (Modbus/TCP vs. BACnet).
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 for analyzing Modbus/TCP network traffic from PCAP files, but does not explicitly state when to use this tool versus the sibling 'parse_bacnet_pcap' or other alternatives. It provides some context (parsing PCAPs for Modbus/TCP) but lacks explicit guidance on exclusions or prerequisites.
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. Dates show when Glama detected each change.
v0.1.0parse_bacnet_pcapparse_modbus_pcapThe two tools have clearly distinct purposes: one parses BACnet/IP traffic and the other parses Modbus/TCP traffic. The descriptions specify different protocols (BACnet vs. Modbus) and outputs (decoded packets vs. transactions), leaving no ambiguity for an agent to misselect between them.
Both tool names follow a consistent verb_noun pattern (parse_bacnet_pcap and parse_modbus_pcap), using the same verb 'parse' and similar noun structures. This predictable naming makes the tool set easy to understand and navigate.
With only 2 tools, the server feels thin for its apparent domain of parsing industrial protocol traffic from PCAPs. While it covers two common protocols, the scope could reasonably include more protocols or related operations, making the count borderline for comprehensive coverage.
The tool set is significantly incomplete for the inferred domain of industrial protocol analysis. It lacks essential operations such as listing available protocols, validating PCAP files, filtering or searching parsed data, and handling other common protocols like DNP3 or OPC UA, which limits agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/desvert/otparse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
