Skip to main content
Glama

packetsniffer_ops

Capture live network, USB, and Bluetooth packets, decode PCAP files, and analyze flows to debug protocols and reverse-engineer device communications.

Instructions

Network interface discovery, live packet capture, and PCAP analysis.

[RATIONALE] Consolidates local packet sniffing, background captures, and offline PCAP analysis tools to stay under tool limits while providing full companion hacking capability.

Operations:

  • list_interfaces: List active network interfaces with details.

  • sniff: Blocking capture for the given count/timeout (requires admin privileges). Pass save_path to persist the capture to a PCAP file for later analysis or evidence.

  • start_capture: Start a capture in the background (non-blocking). Returns a capture_id immediately; the capture runs in a server thread until count/timeout is reached or stop_capture is called. In HTTP daemon mode the capture survives across agent sessions. Poll with capture_status.

  • capture_status: Status of one capture (capture_id) or all active captures.

  • stop_capture: Request a stop (takes effect on the next packet, or at timeout). Returns packets captured so far; pass save_path to persist them.

  • decode_pcap: Deep protocol decode of a PCAP/PCAPNG file via tshark (optional dependency - install Wireshark). Extracts decoded fields Scapy's thin dissectors miss: DNS query/answer names, HTTP requests, TLS SNI hostnames (catches encrypted phone-home domains). Use limit to bound output.

  • analyze_pcap: Parse a PCAP/PCAPNG capture file and summarize network flows.

Hardware-protocol reverse engineering (pure Python, no tshark needed; for working out what bytes a host sends a device such as a label printer):

  • usb_list_hubs: List USB root hubs USBPcap can capture on (needs USBPcap installed; UNVERIFIED live).

  • usb_capture: Capture USB traffic with USBPcapCMD for 'timeout' seconds into save_path (needs USBPcap and administrator rights; UNVERIFIED live). Print/operate the device during the window.

  • usb_payloads: From a USBPcap capture, the data of each transfer (default host-to-device bulk/interrupt), per-endpoint totals, and any device/interface descriptors in the capture (answers "printer class, HID, or vendor-specific?"). export_path writes the concatenated stream to a .bin file.

  • btsnoop_payloads: From a Bluetooth HCI capture (btsnoop, or pcap/pcapng link type 187/201), the RFCOMM serial-port-profile data. Best effort: capture from before the connection is made.

  • diff_captures: Compare two captures' host-to-device streams (file_path vs file_path_b): shared prefix and suffix, changed byte ranges, per-transfer differences. For controlled experiments (blank label vs one dot).

Return Format

{"success": bool, "operation": str, "data": dict | list}

Examples

await packetsniffer_ops(operation="list_interfaces") await packetsniffer_ops(operation="sniff", interface="WiFi", count=10) await packetsniffer_ops(operation="sniff", filter_expr="udp port 53", count=200, timeout=120, save_path="C:/captures/dns.pcap") await packetsniffer_ops(operation="start_capture", filter_expr="udp port 53", count=1000, timeout=300) await packetsniffer_ops(operation="capture_status", capture_id="a1b2c3d4") await packetsniffer_ops(operation="stop_capture", capture_id="a1b2c3d4", save_path="C:/captures/dns.pcap") await packetsniffer_ops(operation="decode_pcap", file_path="C:/captures/dns.pcap", limit=100) await packetsniffer_ops(operation="analyze_pcap", file_path="C:/captures/dns.pcap") await packetsniffer_ops(operation="usb_list_hubs") await packetsniffer_ops(operation="usb_capture", usb_hub="\.\USBPcap1", timeout=30, save_path="C:/captures/02-dot.pcap") await packetsniffer_ops(operation="usb_payloads", file_path="C:/captures/02-dot.pcap", export_path="C:/captures/02-dot.bin") await packetsniffer_ops(operation="btsnoop_payloads", file_path="C:/captures/btsnoop_hci.log", direction="tx") await packetsniffer_ops(operation="diff_captures", file_path="C:/captures/01-blank.pcap", file_path_b="C:/captures/02-dot.pcap")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of packets to capture (default: 50, max: 500).
limitNoMax packets/transfers returned by 'decode_pcap', 'usb_payloads' and 'btsnoop_payloads' (default: 100, max: 500).
timeoutNoTimeout in seconds for capture (default: 10, max: 60).
usb_hubNoUSBPcap filter device for 'usb_capture', e.g. '\\.\USBPcap1' (see 'usb_list_hubs').
directionNoWhich way the bytes travelled. USB: 'out' (host to device, default), 'in', 'both'. Bluetooth: 'tx' (host to device, default), 'rx', 'both'. 'diff_captures' accepts either spelling.out
file_pathNoAbsolute path to the PCAP file for 'analyze_pcap' operation.
interfaceNoNetwork interface identifier (name or GUID) for sniffing.
max_bytesNoBytes of hex shown per transfer in 'usb_payloads' / 'btsnoop_payloads' (default: 256, max: 4096).
operationYesOperation to perform.
save_pathNoAbsolute path to write captured packets as a PCAP file (e.g. 'C:/captures/out.pcap'). Used by 'sniff' and 'stop_capture'.
capture_idNoCapture ID from 'start_capture'. Required for 'capture_status' and 'stop_capture'.
usb_deviceNoUSB device address to select in 'usb_payloads' / 'diff_captures' (default: all devices).
export_pathNoWrite the selected byte stream to this file (.bin/.dat/.raw) for 'usb_payloads' / 'btsnoop_payloads'.
file_path_bNoSecond capture file for 'diff_captures' (file_path is the first).
filter_exprNoBPF filter expression (e.g. 'tcp port 80', 'udp', 'host 192.168.1.100').
usb_devicesNo'usb_capture' only: comma list of device addresses to capture (default: all devices on the hub).
usb_endpointNoUSB endpoint number to select in 'usb_payloads' / 'diff_captures' (e.g. 2 for endpoint 0x02).
transfer_typesNoComma list of USB transfer types for 'usb_payloads': bulk, interrupt, control, isochronous (default: bulk,interrupt).
inject_descriptorsNo'usb_capture': ask USBPcap to inject descriptors of already-connected devices (default: false).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false), and the description carries the burden well beyond them: captures require administrator privileges, start_capture is non-blocking and survives across HTTP daemon sessions, stop_capture only takes effect on the next packet, save_path persists evidence, and dependencies (tshark, USBPcap) are flagged with live-verification caveats. This is exactly the operational context an agent needs before invoking a stateful capture 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?

For a 12-operation, 19-parameter mega-tool the length is largely justified, and the operation-by-operation bullet structure is easy to scan and front-loads the domain statement. Minor waste comes from the '[RATIONALE]' self-justification about tool limits and the somewhat redundant example block, but nothing seriously hinders comprehension.

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 complexity, the description covers prerequisites, blocking semantics, background lifecycle, dependency caveats, and the return envelope ({success, operation, data}), and an output schema exists so return values need no further explanation. Nothing an agent needs to invoke these operations correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter is documented per-operation in the schema, so the baseline is 3. The description repeats most of that (save_path use, limit bounding, direction semantics) rather than adding genuinely new per-parameter meaning, so it does not rise above the baseline.

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 header names the domain (interface discovery, live capture, PCAP analysis) and each of the 12 operations is enumerated with a specific verb+resource, including the distinct USB/Bluetooth hardware-reverse-engineering group. An agent can tell exactly what any given operation does without opening the schema, and the scope is clearly distinct from siblings like workflow/help/status.

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?

Routing guidance is embedded throughout: sniff vs start_capture (blocking vs non-blocking background), decode_pcap vs analyze_pcap (deep tshark decode vs flow summary), and diff_captures 'for controlled experiments (blank label vs one dot)'. Prerequisites are also given (admin rights, tshark optional, USBPcap). What is missing is any explicit 'when not to use' or note on which operation to prefer when an agent is unsure.

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