The Philosophical Developer — Eyes and Hands on Bare Metal: Driving a Home Server with JetKVM over MCP

There is a machine in my house that refuses to be fixed remotely. Small home server, tucked into a corner, running the stuff I rely on. And the classic problem with that class of machine: you cannot SSH into a box that will not boot. When it does go sideways you are staring at a black screen and a spinner, and your agent — the thing that handles everything else — is useless, because it has no eyes and no hands on that hardware.

Mine can now. This is that story.

The problem

Most of my infrastructure is agent-managed. Deployments, config, logs — my agent reaches all of it over the network like I would, only faster. But a machine that dies at boot is below all of that. The OS is not up, so there is no SSH, no agent, nothing. Just the box and the power.

When that happened before, the fix was physical: I sat at the console, watched it try to boot, typed the recovery commands myself. It worked. It also meant the most tedious failure mode of my home lab was the one thing my agent could not touch.

The device

JetKVM is a KVM-over-IP box — HDMI in, USB out. It gives you the machine’s screen and its keyboard, over the network, at the level below the OS. BIOS, bootloader, installer, all reachable with zero SSH on the target and nobody in the room. It is, functionally, a pair of hands at the console you can reach from anywhere.

Then I exposed it to my agent as an MCP server. Twenty-five tools: screenshot, single and double click, move the mouse, type text, press keys, scroll, mount a bootable image as USB media, list what is stored on the device, read power state, wake the host, wake-on-LAN, reboot. Everything I could do with my hands at the console is now a tool call.

What that unlocks

The agent gets the same eyes and hands I have. It can watch the machine’s screen, work through a boot menu, feed it commands, mount an installer image and walk it through recovery — because it is doing what a person at the keyboard would do, not what a script over SSH can.

The first screenshot takes a couple of seconds while the video stream sets up. After that, frames are fast. Typing and clicking land like a real console session. There is no magic; it is literally the machine’s screen and a keyboard, driven by an agent.

The honest bit

Two things you should know before you build this.

First, my unit has no ATX power-extension board, so the hard power control is a no-op. I can soft-reboot, wake-on-LAN, and wake the host, but I cannot cold-power the box on or off. That asymmetry matters when you are planning what the agent is allowed to do to a machine. It is a limitation, not a bug, and easy to forget until the moment you try to hard-cycle a hung host.

Second, reachability is not freedom. Giving an agent console access to a machine below the OS is a real trust boundary. I keep the credentials out of any config my editor or shell would log, and the server talks to it over a local network path. You are handing it the keys to the metal; be deliberate about who holds them.

The direction

This is the automation-of-all-things direction I keep building toward. The agent already reads my logs, writes my code, and runs my cloud. Now it can reach the physical box underneath it all. The gap between “agent operates my infrastructure” and “agent operates my hardware” just closed — and the machine that fixed this was the one sitting dead, refusing to boot, with nobody allowed to sit at the console except me.