MCP server
Give your coding agent
a computer of its own
Kyvenza has an MCP server built in. Point Claude Code, or any MCP client, at it and the agent can start a virtual machine, snapshot it before touching anything, run commands inside the guest, and look at the screen. This is not a chat window bolted onto a VM manager. It is the machine itself, with the guardrails that make handing it over a reasonable thing to do.
Why a virtual machine, and not a container
An agent that can run shell commands needs somewhere those commands cannot reach your Keychain, your SSH keys, or your production credentials. A virtual machine is a boundary the operating system enforces, rather than one your tooling promises. Kyvenza adds the parts a container does not give you: a snapshot you can roll back to in seconds, a disposable clone that costs almost no disk, and a network mode with no network in it at all.
Connected in about a minute
Turn the server on
Settings, then Automation. It is off until you do.
Copy the endpoint
It already carries this Mac’s token. One URL is the whole credential, which is why any client that can take a URL can connect.
Paste it into your client
For Claude Code that is a single command. For clients that read a JSON config, the settings page generates that snippet too.
Claude Code
claude mcp add --transport http kyvenza http://127.0.0.1:59800/mcp/YOUR-TOKENNext to it is a Test connection button that performs a real handshake against your own endpoint and reports how many tools it found. It answers “did I configure this correctly” on the spot, instead of leaving you to find out from a failed tool call later.
What keeps the agent from wrecking your Mac
The server never leaves the loopback interface
It binds 127.0.0.1 and nothing else. No device on your network can see it, and neither can anything on the internet.
Every Mac has its own token
This one deserves the specifics, because the threat is real rather than theoretical. QEMU’s user mode networking translates anything a guest sends to 10.0.2.2 into a connection to the host’s loopback interface. A running Windows guest can therefore reach services bound to 127.0.0.1 on your Mac, including this one. So the endpoint carries a 128-bit token, in the URL path or an Authorization header, and a request without it gets a 401 and nothing else. There is no compatibility mode that turns this off.
The tools that destroy things are off by default
create_vm, clone_vm and delete_vm do not appear in the tool list at all until you enable them. A tool the model cannot see is a tool it will not try, which is a stronger guarantee than refusing the call afterwards.
delete_vm only deletes what it made
It refuses any machine that was not created as a sandbox by clone_vm. What it does delete goes to the Trash rather than being erased, because an agent deleting the wrong thing needs to be undoable.
A snapshot before the agent starts anything
When an agent starts a VM through MCP, Kyvenza takes a snapshot first and reports it in the same response, so the agent knows what to roll back to. Starting a VM yourself from the interface does not do this. It is a safety feature for automation, not a background disk filler.
A machine with no network at all
Any VM can be set to isolated networking. On Linux, with the Kyvenza guest agent installed, you can still run commands and take screenshots after doing that, because that channel is a virtual socket rather than a network.
The fifteen tools
Three of them, marked below, stay hidden until you turn destructive tools on.
| Tool | What it does |
|---|---|
list_vms | Every VM with its OS, status, CPU and memory |
get_vm_status | Status, IP address, display resolution and network mode |
get_vm_ip | The guest IP address of a running VM |
start_vm | Start a stopped VM, taking a snapshot first |
stop_vm | Stop a running VM, gracefully unless you ask otherwise |
restart_vm | Restart a running VM |
suspend_vm | Write the guest’s memory to disk and power off, resuming exactly there next timeLinux only. Use stop_vm for macOS and Windows. |
list_snapshots | The snapshots of a VM, marking which were taken automatically |
take_snapshot | An offline snapshot of a stopped VM |
restore_snapshot | Put a stopped VM back to a snapshot, replacing the current disk |
exec_shell | Run one command in the guest and return exit code, stdout and stderrLinux guests with the guest agent need no network address and no SSH. macOS uses SSH. Windows uses SSH over a loopback-only forwarded port, after the driver installer has been run once inside the guest. |
screenshot | A PNG of the guest’s screenWindows guests are captured on the host side and need nothing installed, no network address, and no display window open. Linux guests with the agent can be captured with no display server at all, because the agent reads the kernel framebuffer directly. macOS needs a signed-in graphical session. |
clone_vmOff by default | Copy a stopped VM into a disposable sandbox, near-instant and almost free on disk |
create_vmOff by default | A new, empty machine with no operating system on it |
delete_vmOff by default | Move a sandbox clone_vm made to the Trash |
Three things this is good at
Run something you do not trust
Clone a prepared VM into a sandbox, let the agent run the installer or the script inside it, read the result, then delete the sandbox. The clone is copy-on-write, so it appears in about a second and costs almost nothing on disk until the guest starts writing. Kyvenza also reclaims expired sandboxes on its own, so an agent that forgets to clean up does not leave you a library full of them.
Check a build on real Windows
The agent can execute commands in a Windows 11 on ARM guest over a forwarded port that is bound to loopback only, and screenshot that guest without anything installed inside it. Useful when the thing you need to know is what the application actually looks like on Windows, not what the test suite says.
Work on a machine with the network unplugged
Set a Linux VM to isolated networking and it has no network adapter at all. The guest agent still answers commands and still takes screenshots, because it runs over a virtual socket. The agent keeps working; the code it is running cannot phone anywhere.
What it does not do
- create_vm gives you an empty machine. Installing an operating system is an interactive process that cannot be driven through MCP, which is why clone_vm from a prepared VM is the tool that matters.
- Running commands inside a Windows guest requires the Kyvenza driver installer to be run once inside Windows, and that first run needs the VM to have internet access.
- The SSH username for a Windows guest has to be plain ASCII. OpenSSH refuses account names containing quotes, spaces or shell metacharacters, which Windows itself allows.
- Snapshots through MCP are disk only and require the VM to be stopped. Saving the memory of a running machine stays a manual action.
- Screenshots of a macOS guest need a graphical session someone has signed into.
Why there is no chat box in the app
We looked at building one and decided not to, for three reasons worth stating plainly. Kyvenza is a one-time purchase and inference is billed per token, so the economics do not work. An in-app assistant that can run arbitrary commands inside a guest pulls in privacy disclosures, data collection declarations and age ratings all at once. And the client you already use is better at being a client than anything we would ship alongside a virtualisation app. So the conversation stays where you already have it, and we build the machine it talks to.
Try it with the machine you already have
The MCP server is in every build, on both the Mac App Store and the direct download. The 7-day trial includes it.