PXE200 SA MCP

Overview Schema Source Related Servers Discussions Admin

Sa Configure

sa_configure

Configure a PXE200 spectrum analyzer in any mode by changing only specified frequency, span, bandwidth, level, attenuation, detector, and sweep parameters, then return the resulting settings.

Instructions

Set up the analyzer (any mode). Only the given parameters change; returns the resulting settings. In HARM / PN / IQS / DET the mode's own controls are used (HARM center/span/level, PN carrier, IQS/DET analysis bandwidth for span). ref_level_dbm is the level at the input: with an external attenuator of 40 dB and a +40 dB offset, ref_level_dbm=20 shows 60 dBm on screen. The offset is applied first, then the reference level (so the input range never drops below the one you asked for).

Input Schema

TableJSON Schema

Name	Required	Description
`rbw`	No	Resolution bandwidth, e.g. '30kHz'
`vbw`	No	Video bandwidth
`span`	No	Span
`stop`	No	Stop
`start`	No	Start (with stop: converted to center+span)
`center`	No	Center frequency, e.g. '915MHz'
`atten_db`	No	Input attenuation
`detector`	No	One of ['Sample', 'PosPeak', 'Average', 'NegPeak', 'MaxPower', 'RMS']
`amp_offset_db`	No	Level offset added to all readings (external attenuator + cal), 0 to clear
`ref_level_dbm`	No	Reference level AT THE INPUT CONNECTOR in dBm (what the ADC sees, BEFORE amp_offset_db). Keep it above the strongest signal at the input to avoid ADC overflow. The tool adds the offset for the on-screen value itself.
`points_accuracy`	No	True = PointsAccuracy (more trace points, slower), False = SweepSpeed

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does solid work: it discloses partial-update semantics ('only the given parameters change'), that it returns resulting settings, how parameters are reinterpreted per mode (HARM/PN/IQS/DET), and the offset-then-reference-level ordering. It doesn't cover failure behavior or persistence, so not a 5.

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 is front-loaded in the first sentence and the remaining sentences each carry non-obvious operational detail (mode mapping, offset ordering). The ref_level example is long but earns its place by resolving an easy-to-misuse parameter.

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 an 11-parameter, all-optional configure tool with an output schema, the description covers the tricky parts (per-mode parameter meaning, ref level semantics, partial updates). Its main omission is routing guidance relative to sa_set/sa_mode, which keeps it short of a 5.

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 baseline is 3, but the description adds genuine meaning beyond the schema: it explains that span maps to analysis bandwidth in IQS/DET and to HARM span/level in HARM/PN, and it clarifies the input-vs-on-screen distinction for ref_level_dbm with a concrete attenuator example.

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?

States a specific verb and resource ('Set up the analyzer') with a scope qualifier ('any mode') and adds per-mode detail about which controls each mode uses. It does not, however, explicitly distinguish itself from settings-adjacent siblings like sa_set, sa_mode, or sa_controls, so an agent must infer the boundary.

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?

Usage is implied rather than stated: 'Only the given parameters change' signals a partial-update configure call, and the mode notes hint at when different parameters apply. With 30+ siblings including sa_set and sa_mode, the absence of any explicit when-to-use-this-vs-that guidance is a real gap.

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