uni-t-uts-mcp

measure

Idempotent

Runs a one-shot spectrum-analyzer acquisition for channel power, OBW, ACPR, TOI, CN, harmonics, or time power, then restores prior settings and generator output even on errors.

Instructions

One-shot measurement that leaves the instrument as it found it: from spectrum analyzer mode it saves the frequency, bandwidth and sweep settings and the tracking generator output (entering a measurement switches it off), enters the measurement (channel_power, time_power, obw, acpr, toi, cn or harmonics) with the given parameters, READs the result, and ALWAYS (even on errors) exits to spectrum analyzer mode, restores the settings and the generator and verifies. With the requested measurement already active it only reads and puts any parameters you changed back. It refuses when the instrument is not in spectrum analyzer mode and the requested measurement is not the active one (use exit_measurement first). Takes the measurement's averaging time.

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": {
      "measurement": "<measurement>"
    },
    "name": "measure"
  }
}

Input Schema

Name	Required	Description
`xdb`	No	obw only: x dB level in dB, -100 to -0.1
`preset`	No	Preset the measurement's parameters when entering (default true)
`average`	No	Measurement averaging on/off
`percent`	No	obw only: occupied power fraction, above 0 up to 1 (0.99 = 99 %); the instrument clamps to 0.9999
`offset_hz`	No	acpr or cn: offset of the adjacent channel (acpr) or of the noise (cn) from the carrier, in Hz, 0 or more
`timeout_s`	No	Seconds to wait for the result (default 30, 1-600); READ waits for the measurement, including its averages
`instrument`	No	Which instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
`measurement`	Yes
`offset_side`	No	acpr only: which adjacent channels to measure
`average_type`	No	Average type
`left_limit_s`	No	time_power only: left limit in s, 0-0.01 (10 ms)
`sweep_time_s`	No	harmonics only: sweep time in s, 0.001-100
`average_count`	No	Averages, integer 1-999 (manual range)
`right_limit_s`	No	time_power only: right limit in s, 0-0.01 (10 ms)
`fundamental_hz`	No	harmonics only: fundamental frequency in Hz
`average_control`	No	Average termination control
`harmonics_count`	No	harmonics only: number of results including the fundamental, integer 2-10 (the preset is 2)
`noise_bandwidth_hz`	No	cn only: noise bandwidth in Hz
`carrier_bandwidth_hz`	No	acpr only: carrier (main channel) bandwidth in Hz
`integration_bandwidth_hz`	No	channel_power, acpr or cn: integration bandwidth in Hz (channel_power: clamped by the instrument to 100 Hz..3.61 GHz)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes far beyond the readOnlyHint=false/idempotentHint=true annotations: it discloses that entering a measurement switches off the tracking generator, that exit and restore happen ALWAYS even on errors, that settings and generator are verified after restore, that changed parameters are put back when the measurement is already active, and that the tool refuses in a specific state. These are exactly the side-effect and cleanup semantics an agent needs before invoking a mutating 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?

The lifecycle is front-loaded (save → enter → READ → always restore → verify) and the refusal condition is held for the end, which is the right order. The prose is dense, though: a two-clause sentence with nested parentheses about the tracking generator and the measurement list slows parsing of what is otherwise a well-ordered narrative.

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 20-parameter mutating tool this covers state prerequisites, side effects, cleanup guarantees, and failure behavior, and no output schema exists so the return value burden falls on the description. It says the result is READ but never characterizes it (units, shape, or what a channel_power vs harmonics result looks like), which is the main remaining gap for a measurement tool.

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 description coverage is 95% across 20 parameters, so the schema already carries the per-parameter meaning and the baseline would be 3. The description adds value at the semantic level: it explains that parameters are applied on entry and reverted if changed while the measurement is already active, and that timeout covers the rounding of averages, tying the parameter set to observable behavior. The one weak spot is the closing line about averaging time, which is ambiguous but not misleading.

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 — a one-shot measurement that saves settings, enters one of seven named measurements, reads the result, and restores the instrument. It also distinguishes itself from the closely related exit_measurement and configure_measurement paths by describing the enter/read/restore lifecycle an agent would otherwise have to compose manually.

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?

Explicitly covers the when: instrument in spectrum analyzer mode and the measurement not already active. It also covers the when-not ("refuses when the instrument is not in spectrum analyzer mode and the requested measurement is not the active one (use exit_measurement first)") and names the fallback, plus the shortcut case where the measurement is already active and only a read is performed.

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

Deploy Server