Testing through MCP: running the suite against a real homelab

While renaming deploy to install across DevStation’s whole stack, the end-to-end suite flagged, within seconds, a regression no mock would have caught: reading the state written by the previous version had broken an endpoint. The test was running against a real Proxmox node, provisioned and destroyed by the flow itself, and that setup is what this post is about.

MCP as an interface, not a category of test

DevStation’s engine exposes an MCP server, and the end-to-end suite drives the CLI through it. These are ordinary integration tests, and MCP does not create a new category of test: it is the interface through which the suite, and any agent, operates the system. The Model Context Protocol is an open standard for connecting agents to tools and data, and in practice the suite goes through the same calls an agent would make: list clusters, provision a node, install a service over SSH, uninstall, destroy. By design, MCP is an inbound adapter that translates the tools into the existing JSON-RPC calls, knowing nothing about the internal structure of the contexts, with an explicit allowlist and risk metadata for the destructive operations.

Real infrastructure instead of mocks

The suite talks to a real machine instead of a simulation: it provisions a node through OpenTofu, brings the VM up, connects over SSH, installs, uninstalls and destroys. It is slower than a unit test, and in exchange what gets verified is what actually happened: a command ran, a resource was created, the response was inspected, and in the end everything was destroyed.

The cycle that became repeatable

That setup is what carried the big refactors. In the rename’s case, the cycle ran in full: the code change, the suite against the real node, the endpoint breaking, the fix to the state reading, and another run until it passed. Catching the regression on the spot, rather than in production, is what made it viable to change names that cut across contract, domain and persistence. And since the agent is the one driving the suite, repeating the cycle after each adjustment costs little.

The Windows validation

Two machines, one Linux and one Windows, shared a directory, with Claude Code running on both. The Linux agent compiled the binary and published the artifacts, and the Windows agent validated, guided by instructions in .md files. The two ran for hours, nearly autonomous, until the whole CLI passed on Windows, with the MCP tests executed from both sides whenever needed. The Windows validation stopped depending on me remembering to repeat a checklist at the end of every change and joined the same cycle, which is good, because I would forget.

Test discipline and the role of the harness

None of this means AI made the complexity disappear. What kept the discipline in place was the harness: every feature ships with its test, every fix with its regression, and the agent runs the real suite because that is the workflow. Testing against the real environment, in a loop, was what most changed the sense of what was safe to attempt in this project.

References

• Model Context Protocol, Anthropic