Skip to main content
Glama

mark_action

Record that the human is about to click this action in the vendor app.

Instructions

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 labels to report/diff_actions instead. A label starting with 'seen' ('seen rpm 1180', 'seen rpm 1180 temp 34') is an observation, not an action: what the vendor app displays right now. It does not end the current action and is never diffed; analysis uses it to name and scale the device's reply readings (rpm = raw, temp = (raw - 40) / 2). Mark it when the human reads a value off the screen. On/off states ('seen pump on', 'seen pump off, alarm on') name single status-flag bits; words ('seen mode silent', 'seen mode turbo, rpm 3900': the word last or before a comma) name a mode byte with a value -> word map; negative values ('seen temp -5') allow signed i8/i16 readings.

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": {
      "label": "<label>"
    },
    "name": "mark_action"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelYesAction label, ideally with a value, e.g. 'brightness 50%' or 'color 255 0 0'; or an observation starting with 'seen', e.g. 'seen rpm 1180 temp 34'
captureNoCapture path whose sidecar markers file (<capture>.actions.json) is updatedcapture.pcapng

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / label / description
      Previous value: -"Action label, ideally with a value, e.g. 'brightness 50%' or 'color 255 0 0'"New value: +"Action label, ideally with a value, e.g. 'brightness 50%' or 'color 255 0 0'; or an observation starting with 'seen', e.g. 'seen rpm 1180 temp 34'"
  2. Changed2 schema fields changedv0.2.1
    • addedInput schema / properties / capture / description
      Added value: +"Capture path whose sidecar markers file (<capture>.actions.json) is updated"
    • addedInput schema / properties / label / description
      Added value: +"Action label, ideally with a value, e.g. 'brightness 50%' or 'color 255 0 0'"
  3. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it names the side effect precisely (appends {label, start, end} to <capture>.actions.json, creating the file) and discloses the non-obvious lifecycle rule that end times are closed only when the next mark arrives. The 'seen' semantics — does not end the current action, never diffed, feeds naming/scaling of readings — is behavioral context an agent could not infer elsewhere.

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?

Purpose and side effects are front-loaded in the first two lines, which is the right ordering. The remaining label-taxonomy prose is dense and would read faster as sub-bullets, but each sentence carries operational information rather than padding.

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?

For a two-parameter marker tool with an output schema (so return values need no explanation), the description covers prerequisites, file target, marker timing, and the full label vocabulary. Nothing an agent needs in order to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description adds substantial meaning beyond it: label grammar for actions vs. observations, the 'seen' prefix's effect on action boundaries, on/off status-bit naming, mode word maps, and signed value handling for negative readings. This is exactly the interpretive layer the schema's terse descriptions cannot supply.

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 opening line is a specific verb plus resource with scope: record that the human is about to click an action in the vendor app. It is clearly distinguishable from siblings by naming capture_start as the prerequisite and pointing to report/diff_actions for the alternate case.

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?

Explicit timing is given (call while capture_start is running, immediately before each click) along with an explicit exclusion and alternative (for a finished Wireshark capture without markers, skip this and pass `labels` to report/diff_actions). It also prescribes a labeling convention (same label stem with varying values) so downstream inference can fit scales.

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