uni-t-uts-mcp

set_amplitude

Idempotent

Configure spectrum analyzer amplitude settings such as reference level, attenuation, preamp, scale, units, and impedance; out-of-range values are clamped and changes reported in warnings.

Instructions

Set amplitude parameters. The power unit is applied first, so reference_level is interpreted in the new unit. Manual attenuation_db turns automatic attenuation off. Out-of-range values are clamped by the instrument; the settings are re-read afterwards and anything it changed is reported in 'warnings'.

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

Input Schema

Name	Required	Description
`preamp`	No	Preamplifier on/off
`instrument`	No	Which instrument to use (a name from list_instruments). Default: the `default` instrument, or the only one configured
`power_unit`	No	Power unit; set before the reference level
`scale_type`	No	Y scale type
`attenuation_db`	No	Manual input attenuation, integer dB 0 to 51; turns automatic attenuation off
`reference_level`	No	Reference level in the power unit in effect after this call (power_unit if given, otherwise the current unit). In dBm the instrument accepts -100 to 30; other values are clamped
`attenuation_auto`	No	Automatic attenuation on/off (not with attenuation_db)
`scale_per_div_db`	No	Scale per division in dB (0.1 to 20)
`input_impedance_ohm`	No	Input impedance in ohms (50 or 75; 75 is a correction for a 75 ohm source)
`reference_level_offset_db`	No	Reference level offset in dB (clamped to +-327.6)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and idempotentHint=true; the description goes further by disclosing that out-of-range values are clamped by the instrument, that settings are re-read after the write, and that any instrument-initiated changes surface in a 'warnings' field. That is meaningful post-write behavior an agent could not derive from the annotations. It is silent on error/failure behavior and on what happens to parameters left unspecified.

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?

Four short sentences, front-loaded with the action, then ordering, then side effects, then failure/feedback handling. The opening sentence is close to a restatement of the tool name, but nothing else is wasted.

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?

For a 10-parameter, all-optional mutation with a 100%-covered schema and no output schema, the description supplies the key missing behavioral facts: ordering, clamping, and the 'warnings' feedback channel. The notable remaining gap is whether omitted parameters are left unchanged, which matters for a setter with no required parameters.

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%, so the schema already documents every parameter including units, ranges and the attenuation_db/attenuation_auto exclusion. The description adds an execution-order constraint and clamping semantics, but most of this is already present in the per-property descriptions, so the added value is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Set amplitude parameters'), which is unambiguous and matches the sibling get_amplitude's read counterpart. It stops short of naming or contrasting that sibling, so the agent must infer the read/write split from names alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

There is no explicit when-to-use / when-not-to-use guidance and no pointer to get_amplitude for reading current settings. However it does give ordering guidance that affects how the call should be composed ('The power unit is applied first, so reference_level is interpreted in the new unit') and interaction rules ('Manual attenuation_db turns automatic attenuation off'), which is implied usage help rather than selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server