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

uni-t-uts-mcp

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

set_ad_audio

Sets AD demodulation speaker and system volume, gates audible changes with confirmation, and restores previous settings unless keep is true.

Instructions

Set the AD (analog demodulation) module's speaker and/or system volume (PM p.158-159, p.9). AD module must be active. Turning the speaker ON, or raising the volume while it is already on, requires confirm=true (loud/unexpected tone in a shared lab, docs/research/analog-demodulation.md risk 3). By default restores the speaker and volume to what they were before this call once the requested change is confirmed by read-back; pass keep=true to leave the new state in place instead. The read path (speaker state, volume) is live-verified (2026-11-12); the speaker-on/volume-raise write path was intentionally not exercised live outside a confirmed, supervised session (the audible side effect this tool's own confirm=true gate exists for).

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

Input Schema

NameRequiredDescriptionDefault
keepNoLeave the new speaker/volume state in place instead of restoring what it was before this call (default false: restore).
confirmNoRequired (true) to turn the speaker on, or to raise the volume while it is already on.
speakerNoTurn the speaker on or off. Turning it ON requires confirm=true: it plays the demodulated signal on the loudspeaker and headphones immediately, at the shared system volume (PM p.158-159, UM p.52; docs/research/analog-demodulation.md risk 3).
instrumentNoWhich instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
volume_pctNoSystem volume in percent, 0-100 (PM p.9). Shared with the rest of the instrument.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say readOnly=false and idempotent=false; the description adds the genuinely non-obvious behavior that changes are reverted after read-back confirmation unless keep=true, plus the audible side effect and confirm gate. It also discloses verification provenance, noting the write path was intentionally not exercised live, which is exactly the kind of caveat an agent needs before mutating hardware.

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?

Front-loaded with the action and prerequisite, then the safety gate, then the default-restore semantics. The final sentence about live verification is long and partly redundant with the confirm discussion, but it carries real information rather than filler.

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 mutating hardware tool with no output schema, the description covers prerequisite state, irreversible-ish audible side effects, the confirm requirement, default restore versus keep, and which code paths are verified. Nothing material 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.

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents keep, confirm, speaker, instrument and volume_pct in detail closely mirroring the description. The description reinforces the confirm/keep interplay but adds no syntax, units, or edge cases beyond the structured fields, so this sits at the baseline for full coverage.

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 concrete verb and resource: setting the AD module's speaker state and/or system volume, with manual page citations. The scope is narrow and unambiguous, and an agent can distinguish it from siblings like set_ad_display or set_ad_filters without opening either 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?

Gives a clear prerequisite (AD module must be active) and the conditions that trigger the confirmation gate (speaker ON, or raising volume while on). It does not explicitly name alternative tools, e.g. get_ad_settings for reading or the sibling setters for other AD parameters, so routing versus alternatives is left to inference.

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