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

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

start_sweep

Start or restart a spectrum analyzer sweep; in single mode, wait for completion or use wait_for_sweep_complete when running without waiting.

Instructions

Start (:INITiate:IMMediate) or restart (:INITiate:RESTart) a sweep. In single mode, wait=true (default) blocks until the sweep is complete; with wait=false call wait_for_sweep_complete next, because over the raw transport the instrument ignores every command while it sweeps (VXI-11 queues them). In continuous mode the sweep is restarted and not awaited. There is no stop/pause/resume: the instrument rejects :INITiate:STOP/PAUSe/RESume.

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

Input Schema

NameRequiredDescriptionDefault
waitNoWait for completion in single mode (default true)
methodNoimmediate (default) or restart
timeout_sNoGive up after this many seconds (default: sweep time + 10 s)
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.8/5.0
Behavior5/5

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

Beyond the lone readOnlyHint=false annotation, it discloses the critical behavioral quirk that over the raw transport the instrument ignores every command while sweeping (VXI-11 queues them) — exactly the fact that determines whether an agent must call wait_for_sweep_complete. It also explains that continuous mode is fire-and-restart rather than awaited, and that stop/pause/resume do not exist.

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 core purpose is front-loaded, then consequences, then the exclusion — a sensible ordering with no filler sentences. It is denser than strictly necessary thanks to parenthetical SCPI mnemonics and the transport aside, but each clause carries operative information.

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 parameterless-required action tool with no output schema and minimal annotations, the description covers the blocking semantics, the transport-level hazard, mode differences, and the unsupported operations. Nothing an agent needs to invoke it correctly (or to know when to call the follow-up tool) 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 already 100%, so the baseline is 3, but the description adds genuine semantics: wait=true is the default blocking behavior in single mode, and in continuous mode there is nothing to await. It does not add anything for timeout_s or instrument beyond what the schema states, which keeps it from a 5.

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 ('Start or restart a sweep') and even maps each mode to its SCPI form (:INITiate:IMMediate vs :INITiate:RESTart). An agent can tell exactly what the tool initiates and how the two modes differ without opening the schema.

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?

States precisely when to use which configuration: single mode with wait=true blocks, single mode with wait=false requires calling wait_for_sweep_complete next, and continuous mode restarts without awaiting. It also names the explicit non-capability ('no stop/pause/resume; the instrument rejects :INITiate:STOP/PAUSe/RESume'), which prevents a doomed invocation.

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