usb-rea
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| capture_startA | Start a USB traffic capture into Side effects: launches a background capture process that keeps writing until capture_stop. Needs elevated privileges on Linux (usbmon; typically root or a usbmon group). Does not touch the device itself. Pair every start with capture_stop; do not start a second capture while one is running. Prefer this over analysis tools when you still need live traffic. |
| capture_stopA | Stop the running capture started by capture_start. Side effects: terminates the background capture process. The pcapng at the path given to capture_start is left on disk for report/diff_actions/scaffold_driver. Returns 'no capture running' if nothing was started (not an error). Call this before analysing. |
| mark_actionA | Record that the human is about to click this action in the vendor app. Side effects: appends {label, start, end} to .actions.json (creates the file).
Call while capture_start is running, immediately before each click; end times are closed
when the next mark arrives. Use the same label stem with different values (brightness 0%,
50%, 100%) so inference can fit scales. For an already-finished Wireshark capture without
markers, skip this and pass |
| diff_actionsA | Diff packets per labelled action and infer the protocol (JSON: byte roles + evidence frames). The JSON also has Read-only analysis: does not write files or talk to hardware. Requires either markers from
mark_action or |
| reportA | Generate a Markdown evidence report: every claim links to frame numbers in the capture. Includes a 'Device responses' section when the device answers queries (status polls, command ACKs, GET_REPORT), saying which reply bytes could not be explained, a 'Handshake' section for messages sent once before the first action (session setup, tokens), and an 'Observations' section for 'seen' markers (named readings and unmatched observations). Read-only: returns Markdown text (does not write a file). Same inputs as diff_actions. Use after capture_stop (or on an existing pcap). Choose this over diff_actions when the human should read the protocol; choose scaffold_driver when they need a pyusb driver. |
| scaffold_driverA | Generate a standalone Python/pyusb driver source for the inferred protocol. One set_() per command; when the device replies, also query_() methods that send the command/poll (or GET_REPORT), read the reply and return it decoded as a dict (readings named by 'seen' markers come back scaled and modes as words, e.g. {'rpm': 1180, 'temp': 34, 'mode': 'turbo', 'ok': True}). When the capture has a handshake, Device() replays it in open() before any command and checks the fixed reply bytes. A command the app only sent in one mode first calls the mode setter (Device(auto_state=False) raises StateError instead). A capture with an image stream to a screen adds send_image(image), which takes JPEG bytes (or, for a raw stream, a Pillow image or RGB565/RGB888 bytes, optionally a region at x, y), chunks it behind the captured header and returns the device's ack. Read-only analysis that returns driver source as text (does not write a file or open the device). Same capture/markers/labels inputs as report. Prefer wireshark_dissector when the goal is to keep decoding traffic in Wireshark; use replay_packet only after the human approved a specific packet from this driver. |
| wireshark_dissectorA | Generate a Wireshark Lua dissector for the inferred protocol. Read-only: returns Lua source as text. Labels commands, decodes values/counters/lookups,
and verifies checksums (usbrea.checksum_ok + expert warning). Load with
|
| hid_descriptorA | Decode a HID report descriptor (and optionally one report payload). Read-only. When |
| replay_packetA | Send one packet to real USB hardware (destructive / irreversible on the device). Side effects: opens the device via libusb/pyusb and writes the packet. Refuses unless user_confirmed=true after the human approved this exact vid/pid/endpoint/hex_data (and setup_hex if any). Needs OS permission to open the device. Prefer scaffold_driver to generate a driver first; never set user_confirmed from an agent guess. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools are clearly distinct: capture_start/capture_stop bracket a session, mark_action records labels, hid_descriptor decodes HID, and replay_packet writes to hardware. The one soft spot is the analysis trio diff_actions/report/scaffold_driver/wireshark_dissector, which take the same capture/markers/labels inputs and differ only in output artifact, but the descriptions explicitly cross-reference ('prefer report when...', 'choose scaffold_driver when they need a pyusb driver') so misselection is largely mitigated.
Everything is snake_case, but the convention is mixed: capture_start/capture_stop use noun_verb while mark_action/replay_packet use verb_noun, and report/scaffold_driver/wireshark_dissector/hid_descriptor are bare nouns with no action verb. Still readable and non-chaotic, but not a single predictable pattern.
Nine tools is well within the sweet spot and each earns its place: capture lifecycle (2), labelling (1), analysis (4 distinct output forms), HID inspection (1), and hardware replay (1). Nothing looks redundant or padded for the stated purpose.
The full workflow is covered end to end: start capture, mark actions/observations, stop, analyze, then export as Markdown, pyusb driver, or Lua dissector, plus a confirmed destructive replay path. Minor gaps: no device/interface enumeration or capture-file discovery tool, and no way to inspect an individual frame or raw packet beyond the frame numbers surfaced by analysis output.