labgrid-mcp: drive a labgrid lab from an LLM agent (or any MCP client) #1951

First my short answers: test execution stays out of the MCP by design, real hardware works today, and a board your nightly holds cannot be power-cycled by an agent.

On scope and test suites. The way I approached this: I treat the MCP as a regulated API surface for the agent, the alternative being a plain shell and hoping for the best. So it exposes the same primitives a developer has with labgrid-client, with gating on top, and deliberately no "run my test suite" verb.

pytest stays pytest. For CI, a conftest fixture that acquires and releases around the session (or the classic reserve --wait / acquire / pytest / release wrapper) is the right shape, reproducible and with no agent involved. I would not put an agent in the quality gate: gates need reproducibility, and agent runs are not reproducible yet. I would say it's more of a tool for helping you during development, and on the fly it can create and run a test against the hardware, but that part is independent of the MCP itself. The MCP is just giving the agent the capability of knowing how to use labgrid. Making it smarter or more specific to your workflow is more the job of skills: a reusable procedure the agent loads (acquire/deploy/run/collect/release, always release when done) that teams adapt to their internal policies, while the MCP stays thin.

Where the agent earns its place is the loop after CI goes red, or during bring-up. A concrete everyday case: a test fails in CI, you tell the agent to investigate the failure from the report, and with the MCP in place it can reserve a device and go debug on real hardware, instead of guessing and asking you to copy and paste outputs back and forth. Your ethernet driver scenario is the same shape: the agent acquires the board, deploys the change, runs whatever you would run by hand (ethtool over ssh_run, or the pytest suite from its own shell), and when a case wedges the board it does what a script did not anticipate: reads the console history, power cycles, reruns just that case, and writes up what differed from the last failure. Every one of those steps is scriptable in advance; composing them in response to what actually happened is not, and that composition is what eats your afternoon. Holding the board through MCP across that whole loop is the point: a per-run fixture releases the moment pytest exits, losing the state you wanted to look at.

A run_pytest style tool (host-side suite as a background job, report pass/fail) would fit naturally; open to it if there is real interest.

And no, not a CLI wrapper underneath: it talks gRPC to the coordinator and drives labgrid's own driver stack, because reservations expire within about a minute without keepalive polling, and console sessions, flash jobs and port forwards all need state that lives across tool calls. The internals are not a stable API, so the version is pinned, a weekly CI job runs against labgrid master, and what I verified is documented with file/line citations in docs/DESIGN.md section 11. Corrections welcome there. Tools: https://github.com/onurcelep/labgrid-mcp#tools

On real hardware. Works today: coordinator locally, plus an exporter with a small YAML for the attached device (resources only exist through an exporter, so that part stays classic labgrid). From there the agent creates the place, adds matches, acquires and drives it. I will reproduce exactly this with a device I have around and share a recording :)

For the nightly case: every driver operation requires the place to be acquired by the agent's own identity, and acquire fails on a held place, so your nightly's board is out of reach. labgrid's own escape hatches (kick, force) still exist as explicit flags, same as labgrid-client gives any human. Beyond that: read-only mode, per-category allowlists, and flashing plus place deletion off unless enabled. The honest limit: nothing rate-limits an agent on a board it legitimately owns; that discipline stays with the agent harness permissions and lab policy, exactly as with a human.

For monitor.sh question it was a local helper for the recording, not in the repo:

#!/bin/bash
# Live observer: labgrid's own client, polling the coordinator's view of
# demo-place. Shows ownership flip as the agent acquires / releases.
export PATH="$HOME/.local/bin:$PATH"
export LG_COORDINATOR=127.0.0.1:20499
green=$'033円[32m'; yellow=$'033円[33m'; dim=$'033円[2m'; bold=$'033円[1m'; rst=$'033円[0m'
while true; do
 out=$(labgrid-client -p demo-place show 2>/dev/null)
 acq=$(printf '%s\n' "$out" | grep -m1 'acquired:' | sed 's/.*acquired:[[:space:]]*//')
 clear
 printf ' %slabgrid-client%s %s· live view%s\n\n' "$bold" "$rst" "$dim" "$rst"
 printf ' place demo-place\n'
 if [ "$acq" = "None" ] || [ -z "$acq" ]; then
 printf ' status %s○しろまる free%s\n holder %s—%s\n' "$dim" "$rst" "$dim" "$rst"
 else
 printf ' status %s●くろまる acquired%s\n holder %s%s%s\n' "$green" "$rst" "$yellow" "$acq" "$rst"
 fi
 printf '\n %s(polling every second — the AI drives, this only observes)%s\n' "$dim" "$rst"
 sleep 1
done

As of v0.1.4 I made acquire information part of uvx labgrid-mcp demo command so no need to run additional monitor on top :)

See you at the next community call. Thanks for actually digging into the repo :)