uni-t-uts-mcp

get_trace_data

Read-only

Read amplitude values of a spectrum-analyzer trace with its frequency or time axis, power unit, trace type, and summary statistics; optionally run a fresh sweep or reduce points by peak-preserving decimation.

Instructions

Read the amplitude values of one trace (1-6, default the selected trace) with the computed frequency axis, the power unit, the trace type and summary statistics (min, max, mean, peak level and peak frequency). The axis is linear from :FREQuency:STARt? to :FREQuency:STOP? over :SENSe:SWEep:POINts? points (zero span has no frequency axis: a time axis from 0 to the sweep time is returned and the result says so). format is ascii (default: about 14 KB, 7 significant digits, no state change, fastest on the unit), real32 (binary, about 4 KB, the same 7 digits) or real64 (binary, about 8 KB, full double precision); for a binary format the instrument's data format is switched for the read and always put back. fresh runs one single sweep first so the data is a complete, current sweep (continuous mode is switched back on afterwards); without it the values are whatever the trace currently holds, which in continuous mode can be mid-sweep. max_points (>= 2) reduces the response by peak-preserving min/max decimation and the result says so with the original count; the statistics always use the full trace. include_axis (default true) adds the per-point axis.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_trace_data"
  }
}

Input Schema

Name	Required	Description
`fresh`	No	Run a single sweep first and read the finished trace; restores continuous mode if it was on (default false)
`trace`	No	Trace 1-6; default the selected trace (:TRACe:SELect?)
`format`	No	Transfer format (default ascii; real32/real64 switch the instrument's :FORMat for the read and restore it)
`instrument`	No	Which instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
`max_points`	No	Return at most this many points using peak-preserving min/max decimation (default: all points)
`include_axis`	No	Include the per-point frequency (or time) axis (default true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description discloses much more: binary formats temporarily switch the instrument's data format and always restore it, `fresh` restores continuous mode afterwards, and zero-span returns a time axis instead of a frequency axis. It even quantifies transfer sizes (14 KB / 4 KB / 8 KB) and precision (7 digits vs full double), which is real behavioral context an agent could not get from the annotations.

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 primary purpose and return contents are front-loaded in the first sentence, with format then freshness then decimation in a logical order. It is dense with semicolons and parentheticals, so it runs long, but nearly every clause carries information an agent needs.

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?

With no output schema, the description carries the full burden of describing returns and does so: amplitude values, computed axis endpoints and point count, power unit, trace type, and the five summary statistics. It also warns that the axis is absent in zero span and that decimated results flag themselves, leaving no material gap for a read-only tool.

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 100%, so the schema already describes all six parameters; the description still adds value by explaining that decimation is peak-preserving and reports the original count, that statistics always use the full trace, and by pinning down precision and payload size per format. Those are semantic consequences the schema field descriptions do not spell out.

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?

Names a specific verb and resource ('Read the amplitude values of one trace') and enumerates the payload: frequency axis, power unit, trace type, and summary statistics. It does not, however, distinguish itself from the sibling get_trace, so an agent must infer which of the two returns data versus settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Guidance is strong at the parameter level — it explains when `fresh` is needed ('without it the values are whatever the trace currently holds, which in continuous mode can be mid-sweep') and when `max_points` matters. It gives no explicit when-to-use-this-tool-vs-alternatives statement, which is the missing piece for a 4 or 5.

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

Deploy Server