uni-t-uts-mcp

get_emi_correction

Read-only

Retrieves one EMI antenna/cable correction set, including enabled status and frequency/gain points, for spectrum analyzer EMI measurements; the EMI module must be active.

Instructions

Read one EMI correction (antenna/cable) factor set: whether it is enabled and its point list (frequency in Hz, gain in dB, added to the measured level at that frequency). EMI module must be active (select_instrument_module).

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_emi_correction"
  }
}

Input Schema

Name	Required	Description	Default
`slot`	No	Correction set number, 1 to 10
`instrument`	No	Which instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only give readOnlyHint=true, so the description carries the rest: it discloses the returned contents, the units (Hz, dB), and the domain meaning that gain is added to the measured level at that frequency. It does not describe behavior for an invalid or unconfigured slot, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences: the payload description is front-loaded and the prerequisite follows as a compact parenthetical cross-reference. Every clause contributes information and nothing is padded.

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?

With no output schema, the description usefully explains what is returned and in what units, plus the module precondition, which is enough to invoke the tool correctly. Minor omissions are error/empty-set behavior and slot numbering semantics beyond the schema's range.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are already documented in the schema, including the 1-10 range and the default instrument resolution. The description's use of 'correction set' hints at the slot parameter but adds no format or edge-case detail beyond the schema, so the baseline of 3 applies.

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?

Uses a specific verb ('Read') with a precise resource ('one EMI correction (antenna/cable) factor set') and even describes the payload (enabled flag plus point list with units and semantics). It is clearly the read counterpart of set_emi_correction and distinct from the other get_emi_* tools.

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?

States a hard precondition and names the sibling that satisfies it: 'EMI module must be active (select_instrument_module).' It does not say when to prefer get_emi_correction over other EMI read tools or what to do if the requested slot is empty, so it falls short of full when/when-not guidance.

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

Deploy Server