openaxpp300s-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAXPP300S_SIM | No | Set to 1 to use the virtual supply simulator instead of real hardware (same as --sim). | |
| OPENAXPP300S_HOME | No | Directory where state/ and data/ files are stored (locks, remembered port, bench limits, logs, jobs, simulator state). If unset, a checkout-local or platform data directory is used. | |
| OPENAXPP300S_PORT | No | Default serial port for the supply (for example COM14). If unset, the port that answered last is used, else the first USB serial port that answers like a PP300S. | |
| OPENAXPP300S_NO_SERIAL | No | Set to 1 to make any real serial port refuse to open. | |
| OPENAXPP300S_SIM_DELAY | No | Scales the simulated answer latency; 0 removes it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Control an AX PP300S buck-boost bench power supply (0-30 V, 0-10.1 A, 300 W) over its USB serial port.
Start with status: measured output voltage/current/power, input voltage, temperature, CV/CC, output on/off, the
values this tool sent last (the supply cannot report its settings) and the bench limits if the user set any.
set sends VSET, ISET, OVP, OCP, DELAY, REV, OPP, OTP and CV/CC priority in a safe order (it never knowingly trips a
protection; with the output on it waits until the output follows VSET). output switches the output on or off and
follows it. param_list writes the five parameter lists of the Chinese screen (VSET/ISET/OVP/OCP only act on the
Digital/Waveform screens; the screen is chosen on the supply, not over serial). display_colors sets the Digital
screen colours. watch samples the status for a while and returns statistics. log_start logs to a CSV/JSONL file in
the background, sequence_start runs timed voltage/current steps; follow both with job_status, end with job_stop.
selftest is read-only; ports finds the supply.
Values are SI units (V, A, W, C). Errors carry a code and a hint: NOT_FOUND (supply not on any USB serial port), BUSY
(port held by another program such as the vendor PC app), NO_REPLY (supply off or in its bootloader),
UNSAFE_OPERATION (over the bench limits or would trip a protection), NOT_APPLIED (acknowledged but the output did not
follow: only detectable with the output on, e.g. the supply shows the Chinese screen).
Every frame, status queries included, makes the supply rewrite one EEPROM cell (the setting under its front-panel
cursor; no wear levelling): poll slowly (watch/log default 1 s) and suggest selecting the DATA box on the supply for
long logs.
Safety: a power supply can damage what is connected. Before switching the output on or raising voltage/current, know
what is connected (ask the user if the bench limits and their note do not say). The bench limits (CLI openaxpp300s limits) are the user's; never ask to raise them yourself without the user's OK. Do not deliberately trip
protections (OVP below the output etc.): the supply sounds an alarm that needs a key press on the front panel, and a
remote ON switches the output on again even then. Settings sent over serial survive a power cycle only if their field
was under the cursor (VSET by default); OPP/OTP/priority only when the settings menu is left on the supply.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusB | Measured output (vout_v, iout_a, pout_w), input voltage vin_v, temperature temp_c, mode (CV / CC / OFF), output_on, plus last_sent (values this tool sent; the supply cannot report its settings, and the front panel may have changed them) and limits (bench limits set by the user). |
| setA | Send settings in a safe order (protections that stay above the output first, setpoints, then protections that must wait for the output to come down). With the output on, waits until the output follows a new voltage (settled). Refused (UNSAFE_OPERATION): values over the bench limits, OVP closer than max(0.2 V, 1.5 %) above VSET (given now or as sent last), an OVP/OCP at or below what the terminals show now, OPP/OTP at the present power/temperature. VSET/ISET/OVP/OCP/DELAY/REV act on the Digital/Waveform screens only: with the output on a VSET that the output does not follow gives NOT_APPLIED; with the output off nothing can be verified, so check vout_v after switching on. |
| outputA | Switch the output on (honours DELAY/REV; waits until the voltage is up: ~1.1 s soft start, about 1.5 s in all; with DELAY or REV over 20 s it returns right after the frame) or off (waits until it is down). With a bench voltage limit set, an output that rises above it is switched off again at once (UNSAFE_OPERATION). The voltage that appears is whatever is in force on the supply (on the Chinese screen: the selected parameter list): check status.vout_v. Know what is connected before switching on. Do not use while the supply's settings menu is open. |
| param_listA | Write one of the five parameter lists (0..4) used by the Chinese screen: voltage, current, OVP, OCP, cut-off current (output off after the current stays below it for about 6 s; 0 = off) and cut-off time (output off when the accumulated on-time reaches it; fields not given are 0). select makes it the active list, sent after the values; it is refused when the list's values are unknown to this tool and a bench voltage limit is set or the output is on. These registers act only while the supply shows the Chinese screen. |
| display_colorsA | Set colours of the Digital screen (firmware >= 1.4.4; saved in the supply's EEPROM). colors: {element: "#RRGGBB" | "0xRGB565" | name}; elements: vout, iout, pout, aux_back, aux_font, bar_back, bar_label, bar_value, bar_onoff, bar_select. reset: true sends the vendor defaults. |
| watchA | Query the status every |
| log_startA | Log the status to a CSV (or JSONL) file in the background: pc_time, local_time, vout_v, iout_a, pout_w, vin_v, temp_c, mode, output_on, cumulative ah and wh. Returns a job id; follow with job_status, end with job_stop. Other tools keep working meanwhile. |
| sequence_startA | Run timed steps in the background: each step sets VSET and ISET, switches the output on and holds |
| job_statusB | State of a log or sequence job (default: the latest): running, the started event, the last sample/step, events (link lost ...), and the summary once it has ended. |
| job_stopB | Stop a log or sequence job (default: every running one) cleanly and return its summary. A sequence switches the output off unless it was started with end: keep. |
| selftestB | Read-only checks: port, status replies and checksums, latency, input voltage and temperature plausible, power = V x I, a bad-checksum frame ignored. Never changes a setting. |
| portsA | List serial ports and ask each USB one for a PP300S status (Bluetooth ports are skipped). The port that answers is remembered for later calls. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct purposes (set vs output vs status vs ports vs selftest). The main overlap is between status, watch, and log_start (all sample the same measurements, differing only in short-run vs background/file), and between set and param_list (different screen/register models). Descriptions provide enough detail to tell them apart, but the boundaries require careful reading.
A partial verb_noun pattern exists (log_start, sequence_start, job_status, job_stop, param_list, display_colors), but several tools are bare nouns or ambiguous single words (set, output, status, ports, watch). The conventions are readable but not predictable—'set' and 'output' are especially terse given the domain.
Twelve tools is well-scoped for a bench power supply: configuration, output control, discovery, measurement, logging, sequencing, job management, and diagnostics each earn their place. No tool feels redundant or trivial.
The lifecycle is well covered: discovery, status/measurement, setting, output switching, background logging and sequencing with job start/status/stop, plus selftest. Minor gaps remain—no way to read back a parameter list's stored values, no job enumeration/listing, and no log file management—but agents can work around these.