Skip to main content
Glama
Sign In
uni-t-uts-mcp

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ad_marker

Idempotent

Configure an AD marker’s mode, trace, reference marker, or position and return its new state. Use it to place or switch markers on AD spectrum and demodulation traces.

Instructions

Set an AD marker's mode, trace, reference marker (delta mode) and/or position, then return its new state. AD module must be active. Commands apply in the order mode, trace, reference, x. AD has six markers per demod type (not SA's ten) and AD-specific traces (rf_spectrum, demod, demod_average, demod_max, demod_min, af_spectrum); x's unit is Hz for the spectrum traces and seconds for the demodulation-waveform traces. A position set on a marker that is off has no effect: set mode normal (or use ad_marker_search) first. Live-verified (2026-11-12) against a real signal.

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": {
      "marker": "<marker>"
    },
    "name": "ad_marker"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoMarker position: Hz for rf_spectrum/af_spectrum, seconds for the demod waveform traces
modeNooff, normal (position), delta or fixed
traceNoTrace the marker sits on
markerYesMarker number, 1 to 6 (AD has six markers per demod type, not SA's ten)
instrumentNoWhich instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
reference_markerNoReference marker for delta mode (another marker, 1-6)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and idempotentHint=true; the description adds real behavioral context on top: the apply order (mode, trace, reference, x), the six-markers-per-demod-type limit versus SA's ten, the concrete AD trace set, the unit semantics of x, and the fact that a position set on an off marker is a silent no-op. That last point is a genuine footgun disclosure an agent cannot infer from structured fields.

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?

Front-loaded with the action and return value, then prerequisites and edge cases in descending importance; every clause about ordering, units, and the off-marker no-op carries operational weight. The trailing 'Live-verified (2026-11-12) against a real signal' is a mild credibility flourish rather than actionable content.

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?

For a six-parameter mutation tool with no output schema, the description covers prerequisites, application ordering, units, the marker-count constraint, and the main failure mode, and it does say it returns the marker's new state. It stops short of describing invalid-input behavior (e.g., out-of-range marker or reference_marker) or what 'fixed' mode does differently, which are the remaining gaps.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description earns above that by explaining that parameters are applied in a fixed sequence (mode → trace → reference → x), which matters when one parameter's validity depends on another (a position set while mode is off is discarded). It does not add much for 'instrument' or spell out delta-mode reference requirements beyond the schema, so not a 5.

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?

States a specific verb and resource ('Set an AD marker's mode, trace, reference marker ... and/or position') plus the side effect ('then return its new state'). It also scopes itself to AD rather than the SA marker family, so an agent can separate it from set_marker/get_marker without opening a schema.

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?

Gives a hard prerequisite ('AD module must be active') and an explicit alternative for the off-marker case ('set mode normal (or use ad_marker_search) first'). It does not explicitly say when to prefer this over get_ad_marker or ad_markers_all_off, but the write-vs-read split is strongly implied by 'set ... then return its new state'.

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

Deploy Server

Other Tools