uni-t-uts-mcp

set_emi_marker

Idempotent

Configure an EMI marker’s mode, trace, reference marker, or frequency on a UNI-T UTS spectrum analyzer, then report any settings the instrument did not accept as warnings.

Instructions

Set an EMI marker's mode, trace, reference marker (delta mode) and/or frequency position. Commands are applied in the order mode, trace, reference, frequency; the marker is re-read afterwards and anything the instrument did not take is reported in 'warnings'. A position set on a marker that is off has no effect: set mode normal (or use emi_marker_search, which turns the marker on) first.

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": "set_emi_marker"
  }
}

Input Schema

Name	Required	Description
`mode`	No	off, normal (position), delta or fixed
`trace`	No	EMI trace, 1 to 3
`marker`	Yes	Marker number, 1 to 6 (EMI has 6 markers)
`instrument`	No	Which instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
`frequency_hz`	No	Marker position in Hz. Not clamped by the instrument
`reference_marker`	No	Reference marker for delta mode (another marker)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the exact application order (mode, trace, reference, frequency), that the marker is re-read after the write, and that rejected values surface in a 'warnings' field. This tells the agent the tool is partially-failing-tolerant and how to detect silent no-ops, which the idempotent/readOnly hints do not convey.

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?

Three sentences, front-loaded with the capability, then evaluation order, then the prerequisite caveat. Dense but every sentence carries operational information; the middle sentence packs two distinct facts (ordering and warnings) that could be split for faster scanning.

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?

There is no output schema, and the description compensates by explaining the 'warnings' return channel and the re-read verification step. Combined with the ordering rules and the off-marker caveat, an agent has everything needed to call it correctly for a six-parameter mutation 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 baseline is 3, but the description adds real meaning: reference_marker only matters in delta mode and frequency_hz is interpreted according to mode, and the fixed application order defines precedence when several fields are supplied. It stops short of clarifying the off/fixed mode semantics or the unclamped Hz behavior.

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?

States a specific verb (Set) and resource (EMI marker) plus the exact settable facets: mode, trace, reference marker for delta mode, and frequency position. This clearly separates it from read-side siblings like get_emi_marker, but it never distinguishes itself from the generic set_marker sibling, which an agent could easily confuse with this EMI-specific variant.

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?

Provides a concrete prerequisite: a position set on a marker that is off has no effect, so set mode normal first or use emi_marker_search, which turns the marker on. That names an alternative and the condition selecting it, though broader guidance (e.g. when to use this versus set_marker) is absent.

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

Deploy Server