rultra puts its sensor box behind an MCP server

What rultra is

rultra runs on a Raspberry Pi 5 on an Elecrow CrowPi learning board. It puts every sensor and actuator behind one Rust trait with one telemetry stream, and it keeps an unusually honest record of how well each device actually works.

Verification is a type in the code, not a comment. A device is Working only when someone observed correct output; otherwise it is Unvalidated, AcksButSilent or Untested. The probe never upgrades a device's level, and tests enforce that a Working claim carries real evidence. The README says outright that it advertises fewer working devices than the board has, on purpose.

What changed

Commit c580e26 on September 13 adds an MCP server exposing ruv:// resources, together with an end-to-end suite. The same burst brings a richer console with live diagrams, and on September 14 commits d1ac3807 and c360ba14 add managed tokens, control badges and a three.js sensor field to the console.

The point of the MCP surface is that the box's verification levels become readable by an agent. A caller gets the same cautious answer the CLI gives, instead of a boolean that hides how much is actually known.

Get started

Rust 1.74 or newer. Tests use a mock backend by default, so no hardware is needed to try it:

git clone https://github.com/ruvnet/rultra && cd rultra
cargo test
./scripts/build-pi.sh

Expected result: the test suite passes on an ordinary development machine with no Pi attached. If a test ever needs real hardware to pass, the README treats that as a leak in the abstraction.

On the Pi itself, the documented commands read the board:

sudo rultra-sense probe
sudo rultra-sense stream 1000

The README at this ref documents the build, probe and stream commands and the console, but it does not document an invocation for the new MCP server. Treat the server as landed in commit c580e26 and read that commit for how it is started, rather than guessing a command.

Use it today

Practical case: bringing up unfamiliar hardware without lying to yourself about it. Input is the board. Workflow is run probe, read the verification level for each device, and only claim a device works once you have observed its output. Output is a JSON-Lines record you can keep.

Acceptance test: run probe against a device you have never visually confirmed. It should report responding true with a verification level below Working. If it reports Working, the honesty rule has been broken and that is a bug.

Push it further

Experimental commentary. The governed loop is the ambitious part: the box measures itself, proposes a configuration change and promotes it only through a fitness gate with canary and verified rollback, recording each step. The README shows a real case where the die hit 83.6 °C, a backoff was proposed, the gate refused it and the change was rolled back.

Limitation: this is one board, one enclosure and one thermal environment, so a gate tuned here is not a general result. Falsifiable test: propose a change that a gate should refuse, and confirm the witness chain records both the refusal and the rollback rather than just the proposal.