Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

EmbeddedCI BenchPod

PYPI · EMBEDDEDCI-MCP · SCANNED SEP 23

Drive a BenchPod hardware-in-the-loop bench: power, flash, UART, I2C, CAN, analog and logic.

Available components

36 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
  • 1 of 31 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency32
Schema Quality & AI Usability0
  • Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.Unverified
Stability & Change Management0
  • Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.Unverified
Tool Coverage0
  • Tool coverage not yet verified: we do not have a sandbox capture of the tool definitions this version of the package serves yet.Unverified
Tool Safety0
  • Tool safety not yet verified: we do not have a sandbox capture of the tool definitions this version of the package serves yet.Unverified
Capabilities0
  • Protocol version not yet verified: we do not have a sandbox capture of the MCP handshake this version of the package performs yet.Unverified

Unverified: 5 categories

Categories scored 0 because our sandbox run of this package has not given us the schema these checks need to read. That is a gap on our side rather than a finding about the package, and we only credit what we can confirm, so the score stands at 0 until the capture succeeds. We are working through the fleet, so this normally clears without any action from you. How we score packages →

Install

How do I install the EmbeddedCI BenchPod MCP server?

EmbeddedCI BenchPod runs locally as a PyPI package, launched with uvx embeddedci-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · embeddedci-mcp

# add to Claude Code
claude mcp add embeddedci-com-embeddedci-mcp -- uvx embeddedci-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "embeddedci-com-embeddedci-mcp": {
      "command": "uvx",
      "args": [
        "embeddedci-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "embeddedci-com-embeddedci-mcp": {
      "command": "uvx",
      "args": [
        "embeddedci-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add embeddedci-com-embeddedci-mcp -- uvx embeddedci-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "embeddedci-com-embeddedci-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "embeddedci-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add embeddedci-com-embeddedci-mcp --command uvx --arg embeddedci-mcp
# ~/.hermes/config.yaml
mcp_servers:
  embeddedci-com-embeddedci-mcp:
    command: "uvx"
    args: ["embeddedci-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "embeddedci-com-embeddedci-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "embeddedci-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add embeddedci-com-embeddedci-mcp -t stdio -c uvx -a embeddedci-mcp
// mcp.json
{
  "mcpServers": {
    "embeddedci-com-embeddedci-mcp": {
      "command": "uvx",
      "args": [
        "embeddedci-mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 23 Sept 26 −33
    • Stability: 0.03 → unverified security
    • Tool safety: pass → unverified security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • Schema quality: 100 → unverified functional
    • Package version: 2.1.0 → 2.1.1 functional
  • 22 Sept 26 0
    • Tool safety: pass → unverified security
    • Stability: Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet. security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • Schema quality: 100 → unverified functional
    • Stability: unverified → 0.03 functional
    • Package version: 2.0.0 → 2.1.0 functional
  • 21 Sept 26 69

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 23 Sept 2026 · Analysed pypi/embeddedci-mcp@2.1.1

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 31 packages
Packages resolved 31
Stale 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 61 exposed · ~6,278 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
adc_read ~59

One calibrated voltage: ext = front SMA (true volts), cal1/cal2 = DAC loopbacks, amp = current terminal. Refused while the input is still moving (e.g. a DAC output left running).

NameTypeReqDescription
sourcestring
NameTypeReqDescription
countintegeryes
sourcestringyes
spanintegeryes
voltagenumberyes

No examples provided.

analog_path ~90

Set every analog mux and relay for a named path in one step. dac_3v3/dac_5v/dac_12v route the DAC to an output; adc_ext connects the ADC to the front SMA; cal1/cal2 loop the 5 V/12 V DAC output back into the ADC; amp reads the current terminal; off parks everything.

NameTypeReqDescription
pathstringyes
NameTypeReqDescription
pathstringyes

No examples provided.

can_close ~20

Clear responder rules and stop CAN (safe when not open).

Input schema present but exposes no named parameters.

NameTypeReqDescription
bitrate
mode
openbooleanyes
term

No examples provided.

can_open ~72

Bring up the pod's CAN interface (replacing any open CAN session).

NameTypeReqDescription
bitrateinteger
modestringnormal = on a bus with other nodes; internal/external = loopback self-test; listen = silent.
termbooleanEngage the 120 ohm termination.
NameTypeReqDescription
bitrate
mode
openbooleanyes
term

No examples provided.

can_read ~68

Read received CAN frames (id, data, timestamps in pod milliseconds).

NameTypeReqDescription
can_id
max_framesinteger
timeoutnumberWith can_id: wait up to this long for it. Without: collect frames for this long (0 = what is buffered).
NameTypeReqDescription
framesarrayyes
matched

No examples provided.

can_respond ~77

Make the pod firmware answer a CAN id instantly (ECU simulation), or clear all rules.

NameTypeReqDescription
clearbooleanRemove all responder rules instead of adding one.
match_extboolean
match_id
reply_data
reply_extboolean
reply_id
NameTypeReqDescription
clearedboolean
rules

No examples provided.

can_status ~22

CAN link state: mode, bitrate, error counters, bus-off.

Input schema present but exposes no named parameters.

NameTypeReqDescription
replyobject

No examples provided.

can_write ~53

Queue one classic CAN frame.

NameTypeReqDescription
can_idintegeryes
data0-8 data bytes.
extboolean29-bit extended identifier.
rtrboolean
NameTypeReqDescription
queuedboolean

No examples provided.

capture_adc ~224

Capture the ADC and summarise it: calibrated stats, dominant frequency and a min/max envelope. Above 32768 samples the capture streams from PSRAM (multi-second captures work). With trigger_la the capture waits for that edge or level, so t = 0 is the trigger moment. The capture is kept for replay and save_capture_as_recording.

NameTypeReqDescription
pointsintegerPoints in the returned min/max envelope.
sample_rate_hzSample rate in Hz; omit for the device maximum.
samplesinteger
sourceRoute this ADC source first; omit to keep routing.
trigger_edgestringWhat starts the capture on trigger_la.
trigger_laWait for an edge or level on this LA channel (a number, or a wiring-profile name) before sampling, so t = 0 is that moment. Omit for a free-running capture. Needs the capture_trigger capability.
trigger_timeoutnumberSeconds to wait for the trigger before the capture is abandoned with a TriggerTimeout.
NameTypeReqDescription
dominant_frequency_hz
durationnumberyes
envelope_maxarrayyes
envelope_minarrayyes
envelope_stepnumberyesSeconds covered by each envelope point.
maxnumberyes
meannumberyes
minnumberyes
peak_to_peaknumberyes
rmsnumberyes
rms_acnumberyes
sample_rate_hznumberyes
samplesintegeryes
source
triggerThe trigger that started the capture, e.g. 'LA9 rising'; null for a free-running capture. t = 0 is the trigger moment.

No examples provided.

capture_correlated ~214

ADC and LA captured from one hardware trigger, so their timebases align. Both are kept. With trigger_la both streams start on that edge or level.

NameTypeReqDescription
adc_sample_rate_hzSample rate in Hz; omit for the device maximum.
adc_samplesinteger
la_sample_rate_hzSample rate in Hz; omit for the device maximum.
la_samplesinteger
pointsintegerPoints in the returned min/max envelope.
stop_dac_afterSeconds into the capture to cut a running DAC.
trigger_edgestringWhat starts both streams on trigger_la.
trigger_laWait for an edge or level on this LA channel (a number, or a wiring-profile name) before sampling, so t = 0 is that moment. Omit for a free-running capture. Needs the capture_trigger capability.
trigger_timeoutnumberSeconds to wait for the trigger before the capture is abandoned with a TriggerTimeout.
NameTypeReqDescription
adcyes
layes

No examples provided.

capture_la ~208

Capture all 14 LA channels and summarise each: levels, edge count, first edge, estimated frequency. With trigger_la the capture starts on that edge or level instead of immediately, so a short event can be caught at a high sample rate. The capture is kept for decode_la and la_timing.

NameTypeReqDescription
sample_rate_hzSample rate in Hz; omit for the device maximum.
samplesinteger
stop_dac_afterSeconds into the capture to cut a running DAC output (see the DUT react).
trigger_edgestringWhat starts the capture on trigger_la.
trigger_laWait for an edge or level on this LA channel (a number, or a wiring-profile name) before sampling, so t = 0 is that moment. Omit for a free-running capture. Needs the capture_trigger capability.
trigger_timeoutnumberSeconds to wait for the trigger before the capture is abandoned with a TriggerTimeout.
NameTypeReqDescription
channelsarrayyes
durationnumberyes
sample_rate_hznumberyes
samplesintegeryes
triggerThe trigger that started the capture, e.g. 'LA9 rising'; null for a free-running capture. t = 0 is the trigger moment.

No examples provided.

capture_uart ~134

Record the DUT's UART output for a fixed window (or until until_regex matches). The channels and baud come from the wiring profile when omitted.

NameTypeReqDescription
baudUART baud rate; omit for the wiring profile's uart_baud.
durationnumberyesCapture window in seconds.
rxLA channel (or wiring name) wired to the DUT's TX; omit for the profile's uart_rx.
txLA channel (or wiring name) wired to the DUT's RX; omit for the profile's uart_tx.
until_regexPython regular expression; stop as soon as it matches.
NameTypeReqDescription
bytesintegeryes
matchedbooleanyes
textstringyes
truncatedbooleanyestext keeps the start and the end when output is long.

No examples provided.

command ~49

Escape hatch for firmware commands no tool covers. Prefer the dedicated tools.

NameTypeReqDescription
requestobjectyesA firmware JSON command with a "cmd" key, e.g. {"cmd": "usb_cc"}.
NameTypeReqDescription
reply

No examples provided.

connect ~159

Open a BenchPod connection (closing any previous one and its sessions) and report status. Over the cloud the device is shared: this takes an exclusive lease, released by `disconnect` or after the server's idle timeout (the next tool call then reconnects).

NameTypeReqDescription
connectionhost[:port] (TCP, default port 8080), a serial device path, 'usb' (auto-detect), 'discover' (mDNS) or 'embeddedci:<device-name>' (cloud). Omit for the server default.
la_voltageSelect the LA I/O-bank voltage right after connecting (the DUT's I/O voltage).
lease_waitnumberCloud only: seconds to wait when another run holds the shared device.
NameTypeReqDescription
capabilities
connectedbooleanyes
connection
firmwareobjectThe pod's raw status report.
kindtcp, serial, discover or embeddedci (cloud).
la_voltageSelected LA bank voltage; null = not set.
leasedboolean
session
warningsarray

No examples provided.

control_loop ~271

Run a tabulated transfer function in the FPGA: each tick out = curve[input], damped and clamped. Needs the loop gateware image, switched to automatically. Poll with loop_probe, move the input with loop_input, stop with dac_stop.

NameTypeReqDescription
curveTransfer function: DAC output codes indexed by input (1-2048 points, spread over the input range).
input_codeinteger
input_map
kintegerDamping, Q15 (32767 = jump straight to the target).
pointsinteger
sharpnessnumberKnee sharpness of the panel preset.
sourceadc = closed loop; fixed = hold input_code (open loop); sweep = advance by step each tick.
stepinteger
switch_imagebooleanIf the pod is on the other gateware image, switch it first (~3 s). The switch resets the FPGA, stopping any DAC output, UART session or I2C sensor emulation. false = fail instead.
tick_divinteger
vmaxinteger
vmininteger
voc_codeInstead of curve: solar-panel I-V preset with this open-circuit code.
NameTypeReqDescription
armedbooleanyes
curve_pointsintegeryes
input_codeintegeryes
kintegeryes
sourceyes
stepintegeryes
switched_imageThe gateware image this call switched the pod to; null when no switch was needed.
tick_divintegeryes
vmaxintegeryes
vminintegeryes

No examples provided.

dac_output ~65

Route a DAC output (3v3, 5v, 12v = ±12 V, or off) and drive a calibrated DC voltage on it.

NameTypeReqDescription
pathstringyes
voltsCalibrated DC volts to drive; omit to only route.
NameTypeReqDescription
codeyes
pathstringyes
voltageyesVoltage produced; null when only routing.

No examples provided.

dac_stop ~20

Stop any DAC output: generator, replay or control loop.

Input schema present but exposes no named parameters.

NameTypeReqDescription
stoppedboolean

No examples provided.

decode_la ~174

Decode I2C (sda, scl), UART (rx, baud) or SPI (sclk + mosi/miso/cs, mode) from LA data. Sample at least ~10x the bit rate. Decoding the last capture again with other channels is free.

NameTypeReqDescription
baud
capturestringlast = decode the previous capture_la; new = capture first (needs samples/sample_rate_hz).
cs
max_itemsinteger
miso
modeinteger
mosi
protocolstringyes
rx
sample_rate_hznumber
samplesinteger
scl
sclk
sda
NameTypeReqDescription
countintegeryes
itemsarrayyes
protocolstringyes
textUART only: the decoded bytes as text.
truncatedbooleanyes

No examples provided.

disable_i2c_sensor ~24

Disarm the emulated sensor (safe when none is active).

Input schema present but exposes no named parameters.

NameTypeReqDescription
stoppedboolean

No examples provided.

disconnect ~26

Close UART/CAN sessions and the connection, releasing a cloud lease. Safe when not connected.

Input schema present but exposes no named parameters.

NameTypeReqDescription
capabilities
connectedbooleanyes
connection
firmwareobjectThe pod's raw status report.
kindtcp, serial, discover or embeddedci (cloud).
la_voltageSelected LA bank voltage; null = not set.
leasedboolean
session
warningsarray

No examples provided.

enable_i2c_sensor ~155

Make the pod act as a BMP280 on sda/scl for the DUT to read. Engage pull-ups on both lines first (set_pull). The channels and address come from the wiring profile when omitted.

NameTypeReqDescription
address7-bit address (BMP280: 0x76 or 0x77); omit for the profile's i2c_addr.
pressure_pa
sclLA channel (or wiring name) of the bus's SCL; omit for the profile's i2c_scl.
sdaLA channel (or wiring name) of the bus's SDA; omit for the profile's i2c_sda.
temperature_c
NameTypeReqDescription
replyobject

No examples provided.

flash ~326

Program the DUT over SWD through the pod's CMSIS-DAP probe (OpenOCD runs on this server's host). The SWD pins, the reset flag and the target config come from the wiring profile when omitted. A failed flash is a normal result (ok=false): read target_unreachable (unpowered, mis-wired or held in reset), stalled, and the log tails to decide what to change.

NameTypeReqDescription
connect_attemptsinteger
connect_under_reset
extra_args
extra_configs
filestringFirmware image path on the machine running this server.
load_addressstringLoad address for raw .bin images, e.g. 0x08000000.
nresetThe target's reset line is wired to the pod's reset pin: enables connect-under-reset. Omit for the profile's swd_nreset.
resetboolean
swclkLA channel (or wiring name) wired to the DUT's SWCLK; omit for the profile's swd_swclk.
swdioLA channel (or wiring name) wired to the DUT's SWDIO; omit for the profile's swd_swdio.
targetstringOpenOCD target config, e.g. target/stm32f4x.cfg; omit for the profile's swd_target.
target_powerPower this eFuse on before flashing.
timeoutnumber
verifyboolean
NameTypeReqDescription
okbooleanyes
returncodeintegeryes
stalledbooleanyes
stderr_tailstringyes
stdout_tailstringyes
target_unreachablebooleanyes

No examples provided.

fpga_image ~87

Reprogram the pod's FPGA with another stored gateware image (~2-3 s). Rarely needed: control_loop, replay and replay_waveform switch automatically. The switch resets the FPGA (any DAC output, UART session or I2C sensor emulation stops).

NameTypeReqDescription
imagestringyesloop = control-loop image; deep_replay = deep DAC replay from PSRAM.
NameTypeReqDescription
featuresintegeryes
imagestringyes
versionintegeryes

No examples provided.

generate ~174

Drive a sine, square or sawtooth on a DAC output (built from 8-bit levels).

NameTypeReqDescription
amplitudenumberyesPeak volts.
dac_pathstring
durationSeconds; omit to run until dac_stop.
freq_hznumberyes
offsetCentre volts; default mid-range of dac_path.
on_capturebooleanStart on the next capture's hardware t0 (phase-locked).
routebooleanRoute dac_path first. false = keep the current analog path (e.g. after analog_path('cal1') for a DAC-to-ADC loopback); dac_path then only sets the volts scaling.
sample_rate_hzSample rate in Hz; omit for the device maximum.
waveformstringyes
NameTypeReqDescription
cotrigbooleanyes
dac_pathstringyes
freq_hznumberyes
waveformstringyes

No examples provided.

gpio_mode ~182

Claim LA channels as GPIO so the pod can drive or read them. A channel stays GPIO — across disconnects — until gpio_release, and while it is GPIO nothing else can use it: release it before uart_open, flash or enable_i2c_sensor on that channel. A channel already owned by another function is refused with a PinConflictError naming the owner, and an engaged bias resistor that would fight the mode with a PullConflictError.

NameTypeReqDescription
laarrayyesLA channels as numbers 1-14 or wiring-profile names.
levelStarting level of an output (default 0) or open-drain channel (default 1, released). Not allowed for input.
modestringoutput = push-pull; open_drain = 0 pulls low and 1 releases; input = high-Z, level readable.
NameTypeReqDescription
pinsarrayyesThe channels this call configured or released.

No examples provided.

gpio_pulse ~153

Emit FPGA-timed pulses on an LA channel — a trigger for the DUT, or a step/dir motor train. The channel must be free or a GPIO output at level 0 (it returns to its GPIO level afterwards). The FPGA runs the train by itself, so this returns as soon as it starts.

NameTypeReqDescription
countintegerNumber of pulses.
layesLA channel 1-14, or a name from the wiring profile — a signal ('READY') or a role ('uart_rx', 'i2c_sda', 'swd_swclk'). Call `wiring` to see the names.
widthnumberyesSeconds the pulse is high (and low between pulses).
NameTypeReqDescription
countintegeryes
laintegeryes
widthnumberyesSeconds each pulse is high (and low between pulses).

No examples provided.

gpio_read ~65

The live level (0/1) of LA channels — omit `la` for all 14. Works whatever owns a channel; a GPIO input is the usual way to watch a DUT output.

NameTypeReqDescription
laLA channels as numbers 1-14 or wiring-profile names.
NameTypeReqDescription
levelsarrayyes

No examples provided.

gpio_release ~80

Stop using channels as GPIO — they go back to high-Z, watched by captures. Omit `la` to release every GPIO channel (channels owned by other functions are left alone). Do this before starting a UART session, flashing or emulating a sensor on those channels.

NameTypeReqDescription
laLA channels as numbers 1-14 or wiring-profile names.
NameTypeReqDescription
releasedarrayyesChannels released; empty list = every GPIO channel.

No examples provided.

gpio_wait ~152

Wait until an LA channel reads `level` (reached=false when the timeout passes first). Polled from this host, so it resolves to a few milliseconds plus the round trip — for precise timing use a triggered capture (capture_la trigger_la) and la_timing instead.

NameTypeReqDescription
layesLA channel 1-14, or a name from the wiring profile — a signal ('READY') or a role ('uart_rx', 'i2c_sda', 'swd_swclk'). Call `wiring` to see the names.
levelinteger0 = low; 1 = high (open_drain: released).
timeoutnumberSeconds to wait.
NameTypeReqDescription
laintegeryes
levelintegeryes
reachedbooleanyesFalse means the timeout passed without the channel reaching level.
waitednumberyesSeconds spent waiting.

No examples provided.

gpio_write ~86

Set the level of GPIO output / open-drain channels (all of them in one pod command). The channels must already be in an output or open_drain mode (gpio_mode).

NameTypeReqDescription
laarrayyesLA channels as numbers 1-14 or wiring-profile names.
levelintegeryes0 = low; 1 = high (open_drain: released).
NameTypeReqDescription
laarrayyes
levelintegeryes

No examples provided.

i2c_sensor_capture ~85

Capture and decode the emulated sensor's I2C bus into a transaction trace (S/Sr/P, addr, data, ACK).

NameTypeReqDescription
addressAlso report whether the DUT addressed this device.
registerWith address: the bytes the DUT read from this register.
sample_rate_hznumber
samplesinteger
NameTypeReqDescription
addressed
addressesarrayyes
register_value
tracestringyes
transactionsintegeryes
truncatedbooleanyes

No examples provided.

i2c_sensor_regs ~34

Read the emulated sensor's register image.

NameTypeReqDescription
lengthinteger
startinteger
NameTypeReqDescription
bytesarrayyes
startintegeryes

No examples provided.

i2c_sensor_status ~29

Emulated sensor state plus bus activity counters — did the DUT talk to it at all?

Input schema present but exposes no named parameters.

NameTypeReqDescription
replyobject

No examples provided.

la_pins ~108

What owns each of the 14 LA channels — none (free), gpio, uart_rx/uart_tx, swd_clk/swd_dio, i2c_sda/i2c_scl or step — plus each channel's GPIO mode, commanded level and bias resistor. Read this when a tool is refused with a pin conflict: it names the owner to stop. Live pin levels come along when the gateware can read them. Captures observe every channel whatever owns it.

Input schema present but exposes no named parameters.

NameTypeReqDescription
levelsLive pin levels; null when the gateware cannot read them (no gpio_read capability).
pinsarrayyes

No examples provided.

la_step ~96

Emit step pulses on an LA channel (step/dir motor drivers); with dir_la, set direction first. The FPGA runs the train by itself; this returns as soon as it starts.

NameTypeReqDescription
delaynumberyesSeconds between step pulses.
dir_la
directioninteger
laintegeryesLA channel (1-14) the signal is wired to.
stepsintegeryes
NameTypeReqDescription
delaynumberyes
laintegeryes
statusstring
stepsintegeryes

No examples provided.

la_timing ~164

Timing of one channel of the last capture_la / capture_correlated: edge timestamps, pulse widths, frequency and duty cycle; with to_la, the delay from its first edge to the next edge on to_la (e.g. a trigger pin to a "result ready" pin). Resolution is one sample; no new capture is taken.

NameTypeReqDescription
afternumberIgnore edges earlier than this many seconds into the capture.
edgestringWhich transitions to list and to time the delay from.
laintegeryesLA channel (1-14) the signal is wired to.
max_edgesinteger
to_edgestring
to_laAlso measure the delay to the next to_edge on this channel.
NameTypeReqDescription
delaySeconds from the first `edge` on la (at or after `after`) to the next `to_edge` on to_la; null when to_la is not given or either edge is missing.
duty_cyclenumberyes
edgestringyes
edge_timesarrayyesEdge timestamps in seconds from the capture start.
frequency_hzFrom the rising edges; null with fewer than two.
high_pulsesyes
laintegeryes
low_pulsesyes
resolutionnumberyesTimestamp resolution in seconds (one sample).
to_la
truncatedbooleanyesMore edges exist than edge_times lists.

No examples provided.

list_waveforms ~28

The organisation's cloud waveform library (needs a cloud connection or BENCHPOD_API_KEY).

Input schema present but exposes no named parameters.

NameTypeReqDescription
waveformsarrayyes

No examples provided.

loop_input ~45

Re-target the running loop's input without re-arming (hold a point, meter, move on).

NameTypeReqDescription
input_code
source
step
NameTypeReqDescription
input_codeintegeryes
output_codeintegeryes
sourceyes
stepintegeryes

No examples provided.

loop_probe ~29

The running loop's live operating point; assert against loop_input, not i, in open-loop runs.

Input schema present but exposes no named parameters.

NameTypeReqDescription
iintegeryesLatest raw ADC reading.
input_codeyes
loop_inputintegeryesThe value the loop indexed the curve with.
sourceyes
vintegeryesDAC code driven this tick.

No examples provided.

measure_power ~209

Measure the DUT's supply current and voltage for a window: average, minimum and peak current, voltage, energy and charge (gap-free sampling, so energy is integrated, not estimated). Use this for a self-contained window (a boot, a sleep interval). To profile across other tool calls, bracket them with power_profile_start / power_profile_stop.

NameTypeReqDescription
durationnumberyesSeconds to sample (blocking).
efuseTarget-power eFuse: 1 = internal 5 V, 2 = external supply. Omit for the wiring profile's rail.
pointsintegerPoints of current/voltage trace to return alongside the statistics; 0 = statistics only.
rate_hznumberSamples per second. Accurate to ~200 Hz; above that the pod delivers what its sampling loop allows, flattening near 365 Hz. rate_hz in the result is what you actually got, adc_rate_hz what the sensor…
NameTypeReqDescription
adc_rate_hznumberConversion rate the current sensor was configured for — the ceiling, not what arrived.
avg_currentnumberyes
avg_powernumberyesWatts (energy over duration).
avg_voltagenumberyes
chargenumberyesCoulombs.
durationnumberyes
efuseintegeryes
energynumberyesJoules, integrated over every sample.
faultbooleanyesThe eFuse tripped (over-current or short) during the profile.
max_voltagenumberyes
min_currentnumberyes
min_voltagenumberyes
nintegeryesRaw samples the statistics cover.
peak_currentnumberyes
rate_hznumberyesSamples per second actually delivered (measured). The pod reads one sensor register per firmware pass, so this lands below what was asked for — roughly 350-450 Hz. Every sample carries its own timest…
trace_currentarrayAmps per trace point.
trace_stepnumberSeconds covered by each trace point.
trace_voltagearrayVolts per trace point.
truncatedbooleanyesSampling stopped at max_duration rather than on request.

No examples provided.

power_cycle_and_capture ~205

Power the target off, then capture UART while it powers back on — the boot banner lands in the window. The channels, baud and power rail come from the wiring profile when omitted.

NameTypeReqDescription
baudUART baud rate; omit for the wiring profile's uart_baud.
delaynumberSeconds into the capture the power comes back.
durationnumberCapture window in seconds; must exceed delay.
efuseTarget-power eFuse: 1 = internal 5 V, 2 = external supply. Omit for the wiring profile's rail.
off_settlenumber
rxLA channel (or wiring name) wired to the DUT's TX; omit for the profile's uart_rx.
txLA channel (or wiring name) wired to the DUT's RX; omit for the profile's uart_tx.
until_regexPython regular expression; stop as soon as it matches.
NameTypeReqDescription
bytesintegeryes
matchedbooleanyes
textstringyes
truncatedbooleanyestext keeps the start and the end when output is long.

No examples provided.

power_off ~70

Switch the target's power rail off. The result says which rail was used.

NameTypeReqDescription
delaySeconds: schedule the power-off pod-side.
efuseTarget-power eFuse: 1 = internal 5 V, 2 = external supply. Omit for the wiring profile's rail.
NameTypeReqDescription
delay
efuseintegeryes
onbooleanyes

No examples provided.

power_on ~84

Switch the target's power rail on. The result says which rail was used.

NameTypeReqDescription
delaySeconds: schedule the power-on pod-side and return at once (e.g. to power on during a capture).
efuseTarget-power eFuse: 1 = internal 5 V, 2 = external supply. Omit for the wiring profile's rail.
NameTypeReqDescription
delay
efuseintegeryes
onbooleanyes

No examples provided.

power_profile_start ~124

Start sampling the target-power rail in the background, then run the steps you want to profile and call power_profile_stop. Replaces any profile already running.

NameTypeReqDescription
efuseTarget-power eFuse: 1 = internal 5 V, 2 = external supply. Omit for the wiring profile's rail.
max_durationnumberSeconds after which the pod stops sampling by itself (the result is then truncated).
rate_hznumberSamples per second; accurate to ~200 Hz, flattening near 365 Hz above that.
NameTypeReqDescription
efuseintegeryes
max_durationnumberyesSeconds after which the pod stops sampling by itself.
rate_hznumberyesSample rate asked for; the achieved rate is in the stop result.
runningboolean

No examples provided.

power_profile_stop ~52

Stop the running power profile and return its statistics (and, with points, a trace).

NameTypeReqDescription
pointsintegerPoints of current/voltage trace to return alongside the statistics; 0 = statistics only.
NameTypeReqDescription
adc_rate_hznumberConversion rate the current sensor was configured for — the ceiling, not what arrived.
avg_currentnumberyes
avg_powernumberyesWatts (energy over duration).
avg_voltagenumberyes
chargenumberyesCoulombs.
durationnumberyes
efuseintegeryes
energynumberyesJoules, integrated over every sample.
faultbooleanyesThe eFuse tripped (over-current or short) during the profile.
max_voltagenumberyes
min_currentnumberyes
min_voltagenumberyes
nintegeryesRaw samples the statistics cover.
peak_currentnumberyes
rate_hznumberyesSamples per second actually delivered (measured). The pod reads one sensor register per firmware pass, so this lands below what was asked for — roughly 350-450 Hz. Every sample carries its own timest…
trace_currentarrayAmps per trace point.
trace_stepnumberSeconds covered by each trace point.
trace_voltagearrayVolts per trace point.
truncatedbooleanyesSampling stopped at max_duration rather than on request.

No examples provided.

power_status ~28

Both target-power rails: eFuse on/off and tripped state, bus voltage and current draw.

Input schema present but exposes no named parameters.

NameTypeReqDescription
externalyes
internalyes

No examples provided.

pull_status ~24

State, direction and value of the bias resistor on LA1-LA8.

Input schema present but exposes no named parameters.

NameTypeReqDescription
channelsarrayyes

No examples provided.

Common questions

What is the EmbeddedCI BenchPod MCP server?

EmbeddedCI BenchPod is an MCP server listed in the public MCP registry as io.github.embeddedci-com/embeddedci-mcp. Drive a BenchPod hardware-in-the-loop bench: power, flash, UART, I2C, CAN, analog and logic. This page covers its PyPI package (embeddedci-mcp).

Is the EmbeddedCI BenchPod MCP server safe to use?

EmbeddedCI BenchPod scores 36 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 23 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the EmbeddedCI BenchPod MCP server expose?

EmbeddedCI BenchPod exposes 61 tools: connect, disconnect, status, set_la_voltage, wiring, and 56 more. Their descriptions and schemas cost roughly 6,278 tokens of context every time the server is loaded.

Is the EmbeddedCI BenchPod MCP server still maintained?

EmbeddedCI BenchPod is still listed as active in the MCP registry. We last reached this channel on 23 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.