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

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_emi_settings

Read-only

Read a snapshot of EMI module configuration, including standard, scan sequence, detectors, traces, and trigger. Limit which setting groups are queried to skip the costly 10-band scan table.

Instructions

Get a read-only snapshot of the EMI module configuration: standard, scan sequence, the 10-band scan table, meter/trace detectors, trace types, search/peak settings, meter frequency and attenuation, and trigger. EMI module must be active (select_instrument_module). By default omits 'scan_table' (10 bands, by far the most expensive group); pass groups including 'scan_table' to include it. A silent or malformed reply to any query is an error naming that command; no partial snapshot is ever returned.

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

Input Schema

NameRequiredDescriptionDefault
groupsNoWhich setting groups to read. Default: all except scan_table (standard, sequence, meters, detectors, traces, search, frequency, amplitude, trigger). Pass an explicit list (including 'scan_table') to change what is read.
instrumentNoWhich 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.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, yet the description adds genuinely new behavior: the cost profile of scan_table, the all-or-nothing contract ("no partial snapshot is ever returned"), and precise failure semantics (silent or malformed reply yields an error naming the command). It does not cover latency/volume of the full snapshot beyond relative cost, but the disclosure is well beyond annotation coverage.

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 purpose, then precondition, then parameter/cost guidance and error contract — every sentence carries information. Slightly dense prose but no filler; the parenthetical enumerations are load-bearing rather than redundant.

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?

For a read-only snapshot tool with only two optional parameters and no output schema, the description supplies the full picture: what is returned, defaults, the costly exception, the precondition, and failure behavior. Nothing an agent needs in order to call it correctly is missing.

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; the description adds real value by explaining the default group list and that scan_table is "by far the most expensive group," which shapes how an agent should set the groups parameter. The instrument parameter's default is left to the schema.

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?

Opens with a specific verb and resource ("Get a read-only snapshot of the EMI module configuration") and then enumerates the exact content returned: standard, sequence, scan table, detectors, traces, search/peak, frequency/attenuation, trigger. This is clearly distinct from siblings like set_emi_scan_table or get_emi_limit_line.

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?

Gives an explicit prerequisite ("EMI module must be active (select_instrument_module)"), states the default group set and why scan_table is excluded, and tells the agent exactly how to change that behavior ("pass groups including 'scan_table'"). It names the sibling needed to satisfy the precondition.

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