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

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

set_ad_filters

Idempotent

Configure low-pass, high-pass, or band-pass/weighting audio filters for an active analog demodulation (AD) module on UNI-T UTS spectrum analyzers.

Instructions

Set the AD (analog demodulation) module's audio filters: low-pass and/or high-pass (freely combinable), or band-pass/weighting (PM p.158-160). AD module must be active. The AM/FM prefix is read fresh from :CONFigure? each call. Live-verified (2026-11-12): low_pass_filter and high_pass_filter can be set together in one call (the instrument does not turn either off for the other), but band_pass_filter is mutually exclusive with both — setting it turns off any active low-/high-pass filter and vice versa (refused locally before sending anything if requested together with either). This tool reads all three before and after and reports in 'warnings' whichever family the instrument turned off that was not explicitly requested.

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

Input Schema

NameRequiredDescriptionDefault
instrumentNoWhich instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
low_pass_filterNoLow-pass audio filter cutoff (PM p.159). Setting this turns the band-pass filter off.
band_pass_filterNoBand-pass/weighting audio filter (PM p.160). Setting this turns the low-pass and high-pass filters off.
high_pass_filterNoHigh-pass audio filter cutoff (PM p.159-160). Setting this turns the band-pass filter off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the AM/FM prefix is read fresh each call, that conflicting band-pass plus low/high-pass requests are refused locally before sending anything, and that the tool reads all three filters before and after and reports unintended changes in 'warnings'. These are meaningful behavioral details for a mutation tool.

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 description is front-loaded with the core operation and then proceeds to interaction rules and warnings behavior. It is fairly dense and includes some extra provenance detail such as 'Live-verified (2026-11-12)', but the information is relevant and not repetitive.

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 filter-setting tool without an output schema, the description covers the essential requirements: active AD module state, combinability constraints, local refusal behavior, and the meaning of the 'warnings' result. Nothing critical for correct invocation appears to be 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 parameter baselines are already documented. The description adds important cross-parameter semantics not fully captured by individual schema fields: low-pass and high-pass can be set together, band-pass is mutually exclusive with both, and the 'warnings' behavior reports which family was turned off unintentionally.

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?

The description states a specific verb and resource: setting the AD module's audio filters, including low-pass, high-pass, band-pass, and weighting filters. This is distinct from sibling tools such as set_ad_audio or set_bandwidth, so an agent can identify the operation 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage conditions: the AD module must be active, low-pass and high-pass are freely combinable, and band-pass/weighting is mutually exclusive with both. It does not explicitly compare this tool to alternative sibling tools, but the filter-specific usage rules are otherwise well specified.

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