Skip to main content
Glama
JacobBeningo

devpsu-mcp

by JacobBeningo
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

devpsu

Agent-friendly bench power supply control, built for the Agentic Firmware Workbench. Set voltage/current, switch the output, and power-cycle the device under test on B&K Precision 1685B/1687B/1688B supplies (and Manson HCS-3xxx, which share the same protocol) — from the command line or from an AI agent via MCP.

Sibling of devpower (USB port power) and devsignal (signal generation). Typical use: an agent's DUT wedges hard enough that a debug-probe reset doesn't help — the agent runs power_cycle on the supply and the board cold-boots.

Supported hardware

Built against the 1687B (36 V / 10 A). The ASCII-over-serial protocol is shared by the 1685B (60 V / 5 A) and 1688B (18 V / 20 A) and the Manson HCS-3xxx family they're based on. USB appears as a virtual COM port (9600 8N1) — no drivers needed on macOS/Linux.

Note for the 1685B: it uses two current decimals; pass --current-decimals 2 (CLI) or current_decimals=2 (API).

Related MCP server: rs3005p-mcp

Install

pip install .

Requires Python 3.10+.

Safety model

An agent controlling DUT power deserves guardrails. devpsu has four:

  1. Session limits (human-in-the-loop) — on the first supply-changing MCP call of a session, the user is prompted (MCP elicitation) for the session's max voltage/current. Agent requests above them require explicit user approval; output_on/power_cycle check the present setpoints too, and output_off is never gated. Hosts without elicitation support fail safe (over-limit requests are refused).

  2. Environment hard ceiling — set DEVPSU_MAX_V / DEVPSU_MAX_A and any request above them is refused before touching the hardware — not even in-session user approval overrides these.

  3. The supply's own protection — devpsu limits --ovp 5.5 --ocp 1.0 programs the instrument's OVP/OCP as a second, firmware-level layer.

  4. Agent-facing guidance — the MCP tool descriptions tell agents to verify setpoints against the DUT's rating before enabling the output.

Also set DEVPSU_PORT to pin the serial port on single-supply benches: auto-discovery probes USB-serial ports with a benign query, which you may not want on a bench with DUT consoles attached.

Multiple supplies

devpsu list shows every supply with its USB location, model maxima, and present setpoints. Identical supplies often ship USB bridges with the same serial number, making /dev/cu.usbserial-* names unstable - so --port (and the MCP port argument) also accepts the location string, which is tied to the physical USB topology:

$ devpsu list
/dev/cu.usbserial-0001  loc=34-2.1.4.1.2.1  max 36.2V/12.0A  set 24.0V/2.0A
/dev/cu.usbserial-4     loc=34-2.1.4.1.4    max 36.2V/12.0A  set 12.1V/3.0A
$ devpsu --port 34-2.1.4.1.4 status     # select by location

Session safety limits are kept per physical supply (keyed by location), so each rail gets its own ceiling and its own approval prompts.

CLI

devpsu list                        # probe for supplies
devpsu status                      # setpoints, live V/A, CV/CC, limits
devpsu set --volts 3.3 --amps 0.5
devpsu on / devpsu off
devpsu cycle --hold 5              # power-cycle the DUT
devpsu limits --ovp 5.5 --ocp 1.0
devpsu raw GETD                    # protocol escape hatch
devpsu --json status               # machine-readable

MCP server

devpsu-mcp runs an MCP server over stdio exposing list_supplies, get_status, set_voltage, set_current, output_on, output_off, power_cycle, and set_protection.

Register with Claude Code (with guardrails):

claude mcp add --scope user devpsu -e DEVPSU_MAX_V=5.5 -e DEVPSU_MAX_A=2 devpsu-mcp

Development

pip install -e ".[dev]"
pytest

The test suite runs against a fake serial layer — no supply required.

License

MIT

Available Tools

6 tools
get_statusA

Full snapshot: setpoints, live output readings (V/A/CV-or-CC), OVP/OCP limits, model max.

ParametersJSON Schema
NameRequiredDescriptionDefault
portNo

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It indicates read-like behavior (retrieving snapshot) but does not disclose any side effects, permissions, or limitations. The description is adequate but not detailed.

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 very concise, using a single sentence with a colon-separated list. It front-loads the key purpose ('Full snapshot'). However, it could be slightly more explanatory without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and one optional parameter, the description provides a list of data categories but lacks structure or format details. It is sufficient for a straightforward read operation but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

The single parameter 'port' has 0% schema description coverage, and the description does not explain its meaning, role, or valid values. The description fails to compensate for the lack of schema documentation.

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 specifies 'Full snapshot' and lists specific data categories (setpoints, live readings, protection limits, model max), clearly indicating the tool retrieves comprehensive status. It distinguishes from sibling tools like set_voltage or output_on which are action-oriented.

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?

The description does not explicitly state when to use this tool versus alternatives like list_supplies. It implies use for detailed status, but no guidance on exclusions or context is provided.

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

list_suppliesA

Probe USB-serial ports for supplies (port + model max V/A).

Probing writes a benign query to candidate serial ports; prefer a pinned DEVPSU_PORT on benches with other serial devices.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

Without annotations, the description fully discloses the side effect of writing a 'benign query' to serial ports, which is critical for an agent to understand. This goes beyond what a read-only annotation would provide, though it omits details about error cases or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero wasted words. The first sentence states the purpose, the second adds essential behavioral context. This is optimally concise.

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?

Given the tool's simplicity (no params, clear purpose) and presence of an output schema, the description is nearly complete. It hints at the output fields ('port + model max V/A'), which suffices for an agent to understand the tool's function.

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?

The tool has no parameters, so per guidelines the baseline is 4. The description adds no parameter information (none needed), and the purpose is clear without them.

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 clearly states the tool's action ('Probe USB-serial ports for supplies') and what information is returned ('port + model max V/A'). This distinguishes it from sibling tools which operate on individual supplies rather than discovering them.

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 provides a behavioral warning ('writes a benign query') and a usage recommendation ('prefer a pinned DEVPSU_PORT'), giving clear context for when to use the tool cautiously. However, it does not explicitly state when not to use it or mention alternatives.

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

output_offA

Switch the output OFF, cutting DUT power immediately. Do not use mid-flash. (Never gated - cutting power is always allowed.)

ParametersJSON Schema
NameRequiredDescriptionDefault
portNo

TDQS

A4/5.0
Behavior5/5

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

No annotations, so description carries full burden. It discloses immediate power cut, the warning about mid-flash, and the 'never gated' behavior indicating no delays or conditions, fully transparent for a simple on/off tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff. Every word adds value: 'Switch the output OFF' (purpose), 'cutting DUT power immediately' (behavior), 'Do not use mid-flash' (usage), '(Never gated...)'(transparency).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of a turn-off function and absence of output schema, the description covers primary purpose and usage constraints. However, the missing explanation of the 'port' parameter is a notable gap, preventing full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema coverage is 0% and description does not explain the 'port' parameter (optional, default null). The user is left wondering what port refers to, which is essential for proper usage.

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 clearly states it switches the output OFF and cuts DUT power immediately, using specific verb and resource. It implicitly distinguishes from sibling 'output_on' by stating 'OFF'.

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?

Provides explicit when-not-to-use: 'Do not use mid-flash.' Adds 'Never gated - cutting power is always allowed' indicating no prerequisites. However, does not explicitly name alternatives like 'output_on' for power on, but context makes it clear.

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

output_onB

Switch the output ON at the present setpoints (session-limit gated). Returns live readings.

ParametersJSON Schema
NameRequiredDescriptionDefault
portNo

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden. It discloses 'session-limit gated' and 'returns live readings,' which add value. However, it does not detail potential side effects, permissions, or error conditions.

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 a single, front-loaded sentence that includes key information. It is concise, though slightly more structure (e.g., breaking into purpose and behavior) could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema or annotations, the description covers the core action and return value but fails to explain the parameter. It is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

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

Schema coverage is 0%, and the description does not mention the 'port' parameter at all. The schema itself provides no description for the parameter. This is a critical gap.

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 clearly states the action (switch output ON), the context (at present setpoints, session-limit gated), and the return (live readings). It distinguishes from sibling tools like output_off and set_voltage/current.

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?

The description implies usage after setting setpoints and before turning output off, but does not explicitly state when to use vs. alternatives like output_off or set_voltage. No exclusions or prerequisites are mentioned.

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

set_currentA

Set the current limit. A tight current limit is the cheapest DUT protection - set it before output_on.

ParametersJSON Schema
NameRequiredDescriptionDefault
ampsYes
portNo

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that setting a tight current limit is protective and should precede output_on, but does not describe idempotency, mutability while output is on, or error conditions. Adequate but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Front-loaded with the core purpose. Efficient and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and two parameters (one undocumented), the description covers the bare essentials: purpose and a usage hint. Lacks details on behavior, side effects, or parameter constraints, which are expected for a minimal viable description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

The description does not explain the 'amps' parameter (units, meaning) or the optional 'port' parameter at all. With 0% schema description coverage, the description should compensate but adds no parameter-level detail beyond the name.

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?

Description clearly states the verb 'Set' and resource 'current limit', distinguishing it from sibling tools like set_voltage. However, it does not explicitly mention the target device (power supply), though sibling context implies it.

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?

Provides explicit usage advice: set the limit before turning output on (output_on). This gives an order-of-operations hint and emphasizes the protection role. No explicit alternatives or when-not-to-use, but the hint is valuable.

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

set_voltageA

Set the output voltage setpoint (does not switch the output on).

Gated by session safety limits: the user is prompted on first use and must approve anything above the session max.

ParametersJSON Schema
NameRequiredDescriptionDefault
portNo
voltsYes

TDQS

A4/5.0
Behavior4/5

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

Without annotations, the description carries the burden and discloses key behaviors: it does not turn on output and has safety limits. However, it omits details like required permissions or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, with two sentences that front-load the main action and provide essential safety context without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description does not describe return values or failure modes. The missing explanation for the 'port' parameter reduces completeness, though the tool is simple.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

The description only implicitly covers the 'volts' parameter and fails to explain the 'port' parameter, leaving its purpose unclear. With 0% schema description coverage, the description should compensate more.

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 clearly states the action ('set the output voltage setpoint') and explicitly notes that it does not switch the output on, distinguishing it from sibling tools like output_on.

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 provides context about safety gating (user prompted on first use, approval needed above session max), which guides appropriate usage, though it does not explicitly contrast with alternatives like set_current.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 6 tool updatesv0.3.0
    • First observedget_status
    • First observedlist_supplies
    • First observedoutput_off
    • First observedoutput_on
    • First observedset_current
    • First observedset_voltage
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool serves a distinct function: probing ports, reading status, setting voltage, setting current, turning output on/off. No overlapping purposes.

Naming Consistency5/5

All tools use consistent snake_case with a verb_noun pattern (list_supplies, get_status, set_voltage, etc.) with no deviations.

Tool Count5/5

6 tools is well-scoped for a power supply controller, covering essential operations without unnecessary clutter.

Completeness4/5

Covers probing, status, voltage/current setting, and output control, but lacks explicit tools for setting OVP/OCP limits, which are only reported in get_status.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • psu-mcp

    mplogas
    F
    license
    Not graded
    quality
    B
    maintenance
    MCP server for programmable bench power supply control, enabling autonomous bootloader-entry probing via precise power cycling and telemetry.
    1
    -

  • rs3005p-mcp

    Gigaclank
    A
    license
    A
    quality
    C
    maintenance
    An MCP server that lets AI agents control an RS PRO RS-3005P/RS-6005P programmable DC power supply over USB/RS232, enabling voltage/current control, measurements, output switching, and memory operations.
    14
    MIT

  • lab-equipment-mcp

    1622352030
    A
    license
    B
    quality
    B
    maintenance
    An MCP server for controlling lab instruments (oscilloscopes, signal generators, etc.) via standardized interfaces like USBTMC, RS-232, and LAN.
    100
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JacobBeningo/devpsu'

If you have feedback or need assistance with the MCP directory API, please join our Discord server