After the order: how an AI agent runs its own VPS over MCP

Most demos of an agent buying a server stop at the moment the order goes through. That's the least interesting moment. The server exists, the agent has an id like 47HZ7YF, and nobody has said what happens next.

Next is everything an admin does without thinking about it: wait until SSH actually answers, find the password, notice the disk filling up, reboot after a kernel update, renew before the month runs out, ask support when something looks wrong. If an agent is going to own infrastructure, it has to do that part too. Here is how that goes over our MCP server. We ran each step in our test environment before writing it down.

If you haven't connected a client yet, start with Claude Code and Codex or Claude Desktop and Cursor.

Minute one: "active" isn't "ready"

order_vps returns as soon as the order is paid from the balance. The server is created in the background, usually in about a minute. The agent's next call is get_vps_status, and it should keep calling it, because that tool is read-only and safe to poll.

Two fields matter. status turns active when the machine exists. access holds what the agent needs to log in: host, port and a ready-made SSH command. On plans with their own IPv4 the port is 22. On NAT plans it's a personal forwarded port, and the response says so explicitly, including a warning not to lock yourself out with a firewall that only allows the outside port.

There's a gap between those two moments that trips people up. The first boot applies OS updates, which can take a few minutes, and SSH may refuse connections in the meantime. A well-behaved agent waits for access.ssh_ready instead of hammering port 22.

If the order had no SSH key, the root password is waiting. reveal_password hands it over exactly once, and only after the VM has finished booting. Ask too early and you get password_pending without using up the one-time reveal. We built it that way after agents kept grabbing a password that the still-booting VM hadn't applied yet. Honestly, though, pass an ssh_key with the order and skip this step entirely.

Day two: watching it

get_vps_metrics returns CPU, memory, network and disk as time series for the last hour, day, week or month. An agent that checks it once a day can notice the pattern that kills small servers: memory creeping up until the OOM killer picks a victim. It can't fix the cause from outside, but it can tell you, or SSH in and look.

power_vps does start, stop and reboot. One detail from testing: if the server isn't active (still being created, or suspended for an unpaid renewal), the tool returns a 409 with a hint to check the status first. An agent that treats every non-200 as "retry forever" will loop here. The error tells it what to do instead, and the error messages are written for agents as much as for people.

set_hostname renames the machine through the guest agent inside it, so the change shows up in the running system without a reboot on Linux. Remove qemu-guest-agent and this tool stops working, returning agent_unavailable and changing nothing.

Day thirty: money

This is where agent-owned infrastructure usually dies. Renewal is someone's calendar reminder, the someone is busy, the server gets suspended.

Here renewal doesn't depend on the agent remembering. Each server renews every month from the prepaid balance, and the account email gets reminders before the date. What the agent has to do is keep the balance above the next charge, and get_balance tells it where things stand.

There is no grace period: if the balance doesn't cover the renewal at the end of the term, the server is suspended and its dedicated IP goes back to the pool.

When the balance is low, topup_balance produces a crypto checkout link: USDT, USDC or ETH on Base, Ethereum or Polygon. And this is the first place the agent needs you. It can generate the invoice; it can't sign a transaction unless you've given it a wallet, and we'd think hard before doing that. In practice people top up once for several months and let the agent spend from that. When an order or invoice was left unpaid because the balance ran short, the agent calls pay_invoice after your top-up and it's paid from the balance.

One honest gap: the MCP tools don't renew a server several months ahead on demand. The monthly renewal is automatic, and paying for 3, 6 or 12 months up front goes through the dashboard or one REST call. If you want a longer term from the start, order_vps takes months (1 to 36) at order time.

get_upgrade_options and change_plan cover growth. The plan changes in place, files and OS stay, the server reboots once, and the price difference for the rest of the period comes off the balance. The agent has to pass confirm: true, which is our way of saying "you're spending money, mean it."

When things go wrong

Destructive actions are deliberately awkward. reinstall_vps and an immediate cancel_service both require the server's exact hostname as confirm, and their descriptions tell the agent to check with a human before calling. That's the second place the agent needs you, and it's on purpose.

The safe cancel, end_of_period, keeps the server until the paid time runs out. undo_cancel takes it back, which matters more than you'd think: agents change their minds mid-task as often as people do.

When the agent is stuck, create_ticket opens a support ticket tied to the server, and reply_ticket continues the thread. A person on our side reads it. It's not a chatbot answering a chatbot.

And when a human has to step in, delegate_service invites them by email as an operator of that one server. They get power, console, reinstall and hostname. They don't get billing, renewal or cancellation, and they never see the agent's token.

What the agent still can't do

To be clear about the limits:

• Fund the balance. It can create a top-up invoice and pay invoices from the balance with pay_invoice. Putting crypto on the balance needs a wallet, which normally means you.
• Work inside the OS through MCP. Packages, configs and deployments go over SSH. MCP manages the box from the outside.
• Lift a suspension on its own. If a server is suspended for abuse, that's a conversation with a person, by design.

None of that makes the tools less useful. It means you should design the agent's loop around them: poll status, keep the balance in range, escalate through a ticket, and wait for you on anything that deletes data.

If the agent's work is short-lived, a full server may not be the right unit at all. VPS or sandbox? covers when a microVM that lives for a minute is the better fit. Otherwise, the plans are here, and the MCP reference lists every tool with its parameters.