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

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

emi_run

Starts an EMI scan sequence, optionally clears the signal list first, and waits up to a specified timeout for the instrument to respond.

Instructions

Start an EMI scan sequence and wait for it, with a time limit. Sends :INITiate2:CONTinuous OFF first (cannot read its prior state first: :INITiate2:CONTinuous? gets no reply in EMI, live-verified), then either :INITiate:FSCan:CLEar:IMMediate (clear_list true: clears the signal list and starts) or :INITiate:IMMediate. There is no documented 'finished' query; completion is inferred from the instrument answering again, since a scan-only sequence was live-verified to leave it silent to everything (including the error queue) for 25 s or more while running, then stop by itself. Reading the resulting signal list is not possible through documented commands (use emi_signal_list actions or the screenshot tool over VXI-11).

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

Input Schema

NameRequiredDescriptionDefault
timeout_sNoGive up waiting after this many seconds (default 45, 0-600). A cold EMI scan was seen to leave the instrument silent to everything, including the error queue, for 25 s or more; reaching this limit does not necessarily mean the scan failed, only that nothing answered in time.
clear_listNoClear the signal list before starting (:INITiate:FSCan:CLEar:IMMediate instead of :INITiate:IMMediate)
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.3/5.0
Behavior5/5

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

The only annotation is readOnlyHint=false, and the description adds substantial behavior beyond it: the exact command ordering, the live-verified fact that ':INITiate2:CONTinuous?' gets no reply in EMI, that there is no documented completion query so completion is inferred from the instrument answering again, and that a running scan silences the instrument (including the error queue) for 25 s or more. That is precisely the context an agent needs to interpret a timeout correctly.

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?

Purpose and timeout bound are front-loaded, then command sequence, then the completion-inference caveat. Every sentence is informative, though the 25 s silence detail is repeated in the timeout_s schema text, making the prose slightly heavier than needed.

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?

Covers the hard parts of a mutation tool with no output schema: command sequence, absence of a completion query, and where to get results. The one gap is that it never says what emi_run itself returns on success, which an agent must guess at since no output schema exists.

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 the timeout_s description already carries the 'silent instrument may not mean failure' caveat. The description clarifies the ordering effect of clear_list (clear the signal list, then start), which adds modest value over the schema's own wording, but does not extend semantics for instrument.

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 ('Start an EMI scan sequence and wait for it, with a time limit') and names the exact SCPI commands it issues. It also distinguishes itself from the tools that read the results ('use emi_signal_list actions or the screenshot tool over VXI-11'), so an agent can separate starting a scan from retrieving its output.

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?

Clear context for use (start-and-wait with a bound) plus an explicit redirect for the follow-up step to emi_signal_list or screenshot. It lacks explicit guidance on what to do when the timeout is hit (e.g., whether to retry or call emi_stop), and it does not contrast itself against emi_stop.

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