Skip to main content
Glama

diff_actions

Diffs captured USB packets by labelled action and infers the device protocol, showing byte roles, handshake, states, responses, and image streams for driver development.

Instructions

Diff packets per labelled action and infer the protocol (JSON: byte roles + evidence frames).

The JSON also has background (periodic polls set aside) and responses: device replies paired with the query they answer (command, background poll or GET_REPORT), with byte roles (const, echo of a query byte, value fitted to the labels, counter, checksum, or reading with its observed min/max) and query/reply frame numbers. A reading that 'seen' markers explain gets name, scale and bias (raw = value * scale + bias, signed for i8/i16) plus the observations in observed; a named mode has table (raw value -> word the app showed); observations lists every 'seen' value and which reply bytes it matched. handshake lists the messages sent once before the first action (request, reply, expect with ?? for token and checksum bytes, uses/tokens for reply bytes reused later as a session token, checksums, retries, reopens, and branches on a step whose reply byte decided what the app sent next). states lists commands the app only sent after a mode command chose one value (also on the command as requires: state, value, count, other values seen, evidence frames), and with source "reply" those it only sent while a named status reply byte showed one mode or flag value (reply, where, reply_frames, and setter: the command seen to make the reply show it). switches lists actions where the app sent a state command first (enter) and maybe again after (restore: "previous", a value or null); that command's packets are kept out of the action, which carries the same switch. streams lists continuous image streams to a screen (JPEG/PNG/GIF/BMP/WEBP, or raw RGB565/RGB888 pixels found by size with raw true): endpoint, endpoints (every host->device endpoint the frame bytes go to, with endpoint_layout 'alternate' or 'blocks' when there are several) and header_endpoint (where the draw command goes, when not with the pixels), format, frame and packet counts, chunk size, per-packet header (nn packet count, ii index, 8 or 16 bit), image size, frame rate, the device's per-frame ack and for raw streams header_packet (the command before each frame, or at the start of its first packet when header_inline is true), region (x/y/width/height fields), byteorder, size_alternatives and channel_order ('rgb' or 'bgr', null = unknown; only settled by frames showing the usb-rea testcard picture, see channel_evidence); those packets are kept out of the commands.

Read-only analysis: does not write files or talk to hardware. Requires either markers from mark_action or labels for a finished capture with pauses between clicks. Prefer report when the human wants a Markdown evidence write-up; prefer scaffold_driver / wireshark_dissector when they want generated code.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "capture": "<capture>"
    },
    "name": "diff_actions"
  }
}

Input Schema

NameRequiredDescriptionDefault
deviceNoUSB device address to analyse; default = bus address with the most host→device payloads
labelsNoMarker-free mode: ';'-separated labels in click order, or a text file path (one label per line). Splits traffic at the largest pauses between host→device messages
captureYesPath to a usbmon or USBPcap pcap/pcapng file
markersNoMarkers JSON path; default <capture>.actions.json. Ignored when labels is set

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.1
    • addedInput schema / properties / capture / description
      Added value: +"Path to a usbmon or USBPcap pcap/pcapng file"
    • addedInput schema / properties / device / description
      Added value: +"USB device address to analyse; default = bus address with the most host→device payloads"
    • addedInput schema / properties / labels
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Marker-free mode: ';'-separated labels in click order, or a text file path (one label per line). Splits traffic at the largest pauses between host→device messages",
      +  "title": "Labels"
      +}
    • addedInput schema / properties / markers / description
      Added value: +"Markers JSON path; default <capture>.actions.json. Ignored when labels is set"
  2. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does state the safety profile directly: 'Read-only analysis: does not write files or talk to hardware.' It also discloses the hard dependency on prior mark_action markers or a labels-mode capture, which is real behavioral context. It stops short of describing failure behavior when neither markers nor labels are available, or how ambiguity in protocol inference is signalled.

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

Conciseness2/5

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

Over 300 words are spent enumerating the structure of the returned JSON — background, responses, handshake, states, switches, streams, channel_evidence — even though an output schema exists and already defines these fields. The result is a dense wall of text between a strong first sentence and a strong final routing sentence, so the genuinely decision-relevant guidance is buried rather than 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 tool's complexity, the definition covers what an agent needs to decide whether to call it: prerequisites, read-only nature, and sibling alternatives. With an output schema present, the extensive return-value prose is unnecessary rather than a completeness gain, but nothing essential to correct invocation 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%, so the schema already documents capture, device, labels and markers including defaults. The description adds only marginal meaning, notably the relationship to mark_action markers and the click-order semantics of labels. Baseline 3 is appropriate since the schema does the heavy lifting.

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 opening sentence gives a specific verb and resource: 'Diff packets per labelled action and infer the protocol', which is concrete enough to distinguish it from analysis siblings. The remainder of the description is almost entirely consumed by output-field enumeration rather than sharpening what the tool does, and the final routing sentence does more to differentiate it than the purpose statement itself.

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?

The closing paragraph is explicit about prerequisites ('Requires either markers from mark_action or labels for a finished capture with pauses between clicks') and names three alternatives with the condition that selects each: report for a Markdown write-up, scaffold_driver / wireshark_dissector for generated code. This is exactly the when-to-use and when-not-to-use guidance an agent needs.

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