Skip to main content
Glama
zhixuan2333

PPK2 MCP Server

by zhixuan2333
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

PPK2 MCP server

A Model Context Protocol (stdio) server that lets an MCP client — Claude Code, Claude Desktop, Cursor — drive a Nordic Power Profiler Kit II (PPK2) over its USB serial port: set mode/voltage, power a device-under-test (DUT), measure current/power/energy, and capture the 8 digital channels as a logic analyser.

The server holds the serial port open for its whole lifetime and serialises every tool call behind one lock, so it is the single owner of the PPK2 — the client talks to the device only through these tools.

Requirements

  • A PPK2 connected over USB

  • uv (the installer below will fetch it if missing)

  • Python ≥ 3.10 (uv will fetch one if needed)

  • Claude Code CLI (optional, for auto-registration)

Related MCP server: buspirate-mcp

One-shot install

git clone https://github.com/zhixuan2333/PPK2-MCP && cd PPK2-MCP
./install.sh          # installs uv, syncs deps, registers the MCP server
./install.sh --run    # ...and immediately launches Claude with a test prompt

install.sh registers the ppk2 server with the Claude Code CLI (claude mcp add, user scope). The serial port is autodetected — no path to configure. Then in Claude:

Use the ppk2 MCP tools to check the PPK2: call ppk2_status, then configure source mode at 3.3V, power the DUT on, measure current for 2 seconds, capture the logic channels for 1 second, and finally power off and disconnect.

Manual setup

uv sync     # create .venv and install dependencies from uv.lock

Run the server standalone (speaks MCP over stdio, so this is mostly a smoke test — Ctrl-C to exit). The PPK2 port is autodetected; override with PPK2_PORT if needed:

uv run ppk2_mcp_server.py
# or pin a port:  PPK2_PORT=/dev/cu.usbmodemXXXX uv run ppk2_mcp_server.py

.mcp.json in this repo also registers the server for any Claude Code session opened in this directory (autodetected port, no edits needed). Approve the project server (or run /mcp) and confirm it shows connected.

Tools

Tool

What it does

ppk2_status

Connection state, mode, voltage, DUT power, available ports. Never opens the port.

ppk2_configure

Open the port, read calibration, set meter mode (ampere/source) + voltage.

ppk2_power

Turn DUT power output ON/OFF.

ppk2_measure

Sample current for N seconds → summary stats (current/power/charge/energy).

ppk2_logic

Capture the 8 digital channels (D0–D7) → per-channel duty, edges, activity.

ppk2_disconnect

Release the serial port.

Modes

  • ampere — the PPK2 measures current drawn from an external supply (it does not power the DUT). voltage_mv is still used for the gain/offset calibration, so set it to your external rail voltage.

  • source — the PPK2 sources voltage_mv to the DUT and measures the current it draws. Use ppk2_power("ON") to enable the output rail.

Serial port resolution

First match wins: a tool's explicit port arg → PPK2_PORT env var → autodetection via ppk2_api.list_devices().

Notes

  • A serial line has a single owner — only one process can hold the PPK2 at a time. Stop other PPK2 tools (e.g. nRF Connect Power Profiler) before using this.

  • Unconnected digital pins float and read a constant/noisy level; drive them from your DUT to see real logic activity.

Available Tools

6 tools
ppk2_configureA

Open the PPK2 and configure it for measurement.

Opens the serial port (if not already open), reads the device calibration, selects the meter mode, and sets the voltage. Call this before ppk2_measure.

Args: mode: "ampere" — the PPK2 measures current drawn from an external supply (it does not power the DUT). voltage_mv is still required and is used for the gain/offset calibration, so set it to your external rail voltage. "source" — the PPK2 sources voltage_mv to the DUT and measures the current it draws. Use ppk2_power("ON") to enable the output. voltage_mv: Source/reference voltage in millivolts (800–5000). port: Serial port override; defaults to PPK2_PORT or autodetection.

Returns the resulting status.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoampere
voltage_mvNo
portNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

Without annotations, the description properly discloses key behaviors: opens serial port if not already open, reads calibration, selects mode, sets voltage. It also describes mode-specific behavior (voltage_mv usage in ampere vs source). However, it doesn't mention error conditions or what happens on failure, though output schema may cover return values.

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 concise and well-structured: a one-sentence summary, followed by detailed behavioral steps, then clear argument explanations. Every sentence adds value with no redundancy.

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?

The description covers the main function, all parameters, usage sequence, and mode-specific behavior. Output schema exists for return format. Minor omission: no mention of behavior on repeated calls or error handling, but overall it's sufficiently complete for a configuration tool.

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

Parameters5/5

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

Schema has 0% description coverage, but the description adds extensive meaning: mode options with detailed explanations (external vs source), voltage_mv range (800-5000) and purpose, port override mechanism. This fully compensates for the schema's lack of descriptions.

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 'Open the PPK2 and configure it for measurement' with specific verb and resource. It distinguishes from siblings by mentioning 'Call this before `ppk2_measure`' and referencing `ppk2_power` for enabling output, making its unique role evident.

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

Usage Guidelines5/5

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

The description explicitly says 'Call this before `ppk2_measure`' and explains when to use each mode ('ampere' vs 'source'), including that 'ampere' mode requires external supply and 'source' mode needs `ppk2_power("ON")`. This provides clear context for usage and alternatives.

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

ppk2_disconnectA

Release the serial port (stops sampling and drops DUT power first).

Use this to hand the port to another process, or to recover from a wedged connection — the next tool call will reopen it.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Discloses that the tool stops sampling and drops DUT power before releasing the port. Also notes that the next tool call will reopen the port. This provides important behavioral context beyond just 'disconnect', which is critical for a hardware 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?

The description is two sentences, both front-loaded with the core action and purpose. Every sentence is useful and there is no waste. It is appropriately sized for the tool's simplicity.

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

Completeness5/5

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

Given zero parameters and an existing output schema, the description covers all necessary context: what it does, when to use it, side effects (drops DUT power, stops sampling), and lifecycle hint (next call reopens). No gaps.

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?

There are no parameters, so the description does not need to add parameter semantics. The baseline of 4 is appropriate as the schema coverage is 100% and there is nothing to explain.

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 that the tool releases the serial port, stops sampling, and drops DUT power. It also provides the purpose: to hand the port to another process or recover from a wedged connection. This distinguishes it from sibling tools like ppk2_configure or ppk2_measure.

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

Usage Guidelines5/5

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

Explicitly says when to use: to hand the port to another process or recover from a wedged connection. It also implies that after disconnecting, the next tool call will reopen, which helps the agent understand the lifecycle.

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

ppk2_logicA

Capture the PPK2's 8 digital logic channels (D0–D7) — a logic analyser.

The PPK2 samples 8 digital inputs alongside current at ~100k samples/s. This starts sampling, discards a settling window, collects digital states for duration_seconds, and returns per-channel statistics: the fraction of time each channel was high, the number of edges (level transitions), and the first/last observed level. Requires a prior ppk2_configure.

Note: unconnected digital pins float and may read a constant or noisy level; drive them from your DUT to see real activity.

Args: duration_seconds: Capture window after settling. 0.05–60. settle_ms: Initial samples discarded before timing starts. Default 100 ms. channels: Which channels (0–7) to report. Default all eight. include_series: If true, also return a downsampled level series per channel (each point is the fraction high over that block, 0.0–1.0). series_points: Target number of points in each downsampled series.

Returns sample count, achieved sample rate, and a channels map keyed by channel index.

ParametersJSON Schema
NameRequiredDescriptionDefault
duration_secondsNo
settle_msNo
channelsNo
include_seriesNo
series_pointsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

The description details the sampling process: starts sampling, discards a settling window, collects states for duration, and returns statistics. It also warns about unconnected pins floating. With no annotations, this provides reasonable behavioral context, though it does not state whether it is read-only or if it affects concurrent measurements.

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 well-structured: a one-sentence purpose, followed by process explanation, a behavioral note, and a labeled Args list. Every sentence adds value, with no redundancy, fitting within a moderate length.

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

Completeness5/5

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

The description covers the prerequisite (ppk2_configure), the sampling process, parameter details, output structure (sample count, sample rate, channels map), and a behavioral note on floating pins. Given the presence of an output schema, this fully equips an agent to use the tool correctly.

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

Parameters5/5

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

The description explains all five parameters: duration_seconds range (0.05–60), settle_ms default (100 ms), channels (0–7, default all), include_series (if true returns downsampled series), and series_points (target points). This adds significant meaning beyond the bare schema, which has no descriptions.

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 opens with a clear verb 'Capture' and specific resource 'PPK2's 8 digital logic channels (D0–D7)', immediately distinguishing it from sibling tools like ppk2_measure which focus on current/power. The mention of 'logic analyser' reinforces its purpose.

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 states 'Requires a prior ppk2_configure', providing a necessary prerequisite. However, it does not explicitly advise when to use this tool over alternatives (e.g., ppk2_measure for current-only analysis) or when not to use it. The context with siblings implies differentiation, but explicit guidance is missing.

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

ppk2_measureA

Sample current for a fixed duration and return summary statistics.

Starts continuous sampling, discards an initial settling window, collects samples for duration_seconds, stops, and computes statistics. Requires a prior ppk2_configure. The PPK2 streams ~100k samples/s, so raw samples are never returned by default — only aggregates (and an optional downsampled series).

Args: duration_seconds: How long to collect samples (after settling). 0.05–60. settle_ms: Initial data discarded before timing starts, to skip the switch-on transient. Default 200 ms. include_series: If true, also return a downsampled current series. series_points: Target number of points in the downsampled series.

Returns current statistics in microamps (µA), plus average power (µW), charge (µC) and energy (µJ) when a voltage is configured. samples is the raw sample count; sample_rate_hz is the achieved rate.

ParametersJSON Schema
NameRequiredDescriptionDefault
duration_secondsNo
settle_msNo
include_seriesNo
series_pointsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: it starts continuous sampling, discards a settling window, collects samples, stops, and computes statistics. It reveals the sampling rate (~100k samples/s), that raw samples are never returned by default, and explains the downsampled series option. Returns are detailed with units.

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 well-structured with an introductory sentence, process flow, parameter list, and return description. While comprehensive, it maintains clarity without excessive verbosity. The use of bullet points for arguments and clear sectioning earns a high score, though a slight reduction for minor redundancies (e.g., 'Args:' could be more compact).

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

Completeness5/5

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

Given no annotations and the tool's complexity (hardware interaction, prerequisite, high-frequency sampling), the description is remarkably complete. It covers prerequisites, process, parameter constraints, return values, and edge cases (settling window). The presence of an output schema further supports completeness.

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

Parameters5/5

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

The schema description coverage is 0%, but the description fully compensates: it defines each parameter with purpose, defaults, ranges (duration_seconds: 0.05–60, settle_ms: default 200), and semantics (include_series as a flag, series_points as target count). This adds significant meaning beyond the schema fields.

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 uses a specific verb ('Sample') and a clear resource ('current') with scope ('for a fixed duration and return summary statistics'). It clearly distinguishes from sibling tools like ppk2_configure (setup) and ppk2_power (power control) by describing a measurement action.

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 explicitly states the prerequisite ('Requires a prior ppk2_configure') and outlines the process (continuous sampling, settling window, collection, stopping). It implies when to use (after configuration) but does not explicitly mention when not to use or alternative tools, though the sibling context provides differentiation.

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

ppk2_powerA

Turn the DUT power output ON or OFF.

In source mode this enables/disables the voltage the PPK2 sources to the DUT. In ampere mode it connects/disconnects the PPK2's internal switch in the current path. Requires ppk2_configure to have been called first.

Args: state: "ON" or "OFF".

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior3/5

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

Describes internal actions (enable/disable voltage, connect/disconnect switch) and prerequisite. No annotations provided, so description carries full burden; lacks details on side effects or state persistence.

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?

Front-loaded with main purpose, mode explanation, and prerequisite. Could be slightly more concise, but structure is clear.

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?

Covers prerequisite, mode behavior, and parameter values. Output schema exists (not shown), so return value not needed. Adequate for a simple on/off tool.

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?

Only parameter 'state' has no schema description; description provides valid values 'ON' or 'OFF' in Args, adding meaning beyond the schema's generic string type.

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?

Clear verb and resource: 'Turn the DUT power output ON or OFF.' Explains behavior in source and ampere modes, and distinguishes from sibling tools by focusing on power control.

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?

States prerequisite: requires `ppk2_configure` first. Explains mode-dependent behavior. Lacks explicit comparison to alternatives but provides sufficient context.

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

ppk2_statusA

Report PPK2 connection and configuration state.

Returns whether a device is connected, the resolved/candidate serial port, the active meter mode, the configured source/reference voltage, the last commanded DUT power state, and any serial ports that look like a PPK2. Safe to call any time; never opens the port.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

No annotations provided, so description carries full burden. It fully discloses behavioral traits: non-destructive (never opens the port), returns specific state fields, and is safe to call anytime. No contradictions.

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 with no filler. Lists all returned fields efficiently. Front-loads purpose in first sentence. Every word earns its place.

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

Completeness5/5

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

For a simple status tool with output schema and no parameters, the description fully covers what the tool does, when to use it, and its behavioral transparency. Complete.

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?

Input schema has 0 parameters, so baseline is 4. Description does not add parameter info because none exist, which is appropriate. No need for further elaboration.

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?

Description clearly states it reports PPK2 connection and configuration state, listing specific return fields. Differentiates from sibling tools which are action-oriented (configure, disconnect, measure, etc.).

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?

Explicitly says 'Safe to call any time; never opens the port,' indicating it's non-destructive and can be used for pre-checks. Lacks explicit when-not or alternatives, but the sibling list provides context.

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.

  1. 6 tool updatesv0.1.0
    • First observedppk2_configure
    • First observedppk2_disconnect
    • First observedppk2_logic
    • First observedppk2_measure
    • First observedppk2_power
    • First observedppk2_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool addresses a distinct aspect of PPK2 operation: configuration, disconnection, logic capture, current measurement, power control, and status reporting. There is no overlap in functionality.

Naming Consistency5/5

All tools follow a consistent `ppk2_<verb_or_noun>` pattern. The names clearly indicate their action (configure, disconnect, measure, power, status) or feature (logic), making them predictable.

Tool Count5/5

Six tools is a well-scoped set for a PPK2 hardware interface. Each tool maps to a required operation for using the device, without unnecessary bloat or missing essentials.

Completeness4/5

The tool set covers the full workflow: configure, power control, measurement, logic analysis, and cleanup. A very minor gap is the absence of a separate tool to read calibration data, but configure handles it implicitly.

Maintenance

ActivityStale
ResponsivenessNo issues

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

  • joulescope-mcp

    juanqui
    A
    license
    A
    quality
    F
    maintenance
    MCP server for the JouleScope JS220 precision energy analyzer, enabling agents to measure current, voltage, power, charge, and energy via tools like measure_energy.
    10
    2
    Apache 2.0

  • buspirate-mcp

    mplogas
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for BusPirate 6 hardware security testing. Exposes UART, SPI, I2C, 1-Wire, power supply, GPIO, and logic analyzer operations as tools.
    2
    MIT

  • ppk2-mcp

    Ultrahuman-tech
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for Nordic Semiconductor's Power Profiler Kit II (PPK2), enabling current measurement and device control via 12 tools from Claude.
    1
    MIT

  • dsview-mcp

    modelclixxo
    F
    license
    Not graded
    quality
    C
    maintenance
    Local MCP server for building an agent-facing integration around DreamSourceLab DSView. Enables native logic capture, protocol decode, and analysis with artifact management for I2C, SPI, and UART.
    -