Dopo l'ordine: come un agente IA gestisce da solo il proprio VPS via MCP

Quasi tutte le demo di un agente che compra un server si fermano nel momento in cui l'ordine va a buon fine. È il momento meno interessante. Il server esiste, l'agente ha un id come 47HZ7YF e nessuno ha detto cosa succede dopo.

Dopo arriva tutto ciò che un amministratore fa senza pensarci: aspettare che SSH risponda davvero, trovare la password, accorgersi che il disco si riempie, riavviare dopo un aggiornamento del kernel, rinnovare prima della fine del mese, chiedere al supporto quando qualcosa non torna. Se un agente deve possedere infrastruttura, deve occuparsi anche di questo. Ecco come funziona con il nostro server MCP. Abbiamo provato ogni passo nel nostro ambiente di test prima di scriverlo.

Se non hai ancora collegato un client, parti da Claude Code e Codex o da Claude Desktop e Cursor.

Primo minuto: «active» non vuol dire «pronto»

order_vps risponde appena l'ordine è pagato dal saldo. Il server viene creato in background, di solito in circa un minuto. La chiamata successiva dell'agente è get_vps_status, e può ripeterla quanto vuole: lo strumento legge e basta.

Contano due campi. status diventa active quando la macchina esiste. In access c'è ciò che serve per entrare: host, porta e un comando SSH pronto. Sui piani con IPv4 propria la porta è 22. Sui piani NAT è una porta inoltrata personale, e la risposta lo dice chiaramente, con l'avviso di non chiudersi fuori con un firewall che consente solo la porta esterna.

Tra questi due momenti c'è un buco in cui si inciampa. Il primo avvio installa gli aggiornamenti del sistema, che possono richiedere qualche minuto, e nel frattempo SSH può rifiutare le connessioni. Un agente accorto aspetta access.ssh_ready invece di martellare la porta 22.

Se l'ordine non aveva una chiave SSH, ti aspetta la password di root. reveal_password la consegna esattamente una volta e solo quando la VM ha finito di avviarsi. Se chiedi troppo presto ricevi password_pending senza consumare la visualizzazione unica. L'abbiamo fatto così dopo che gli agenti continuavano a prendere una password che la VM, ancora in avvio, non aveva applicato. Ma, sinceramente, passa una ssh_key nell'ordine e salta questo passaggio.

Secondo giorno: tenerlo d'occhio

get_vps_metrics restituisce CPU, memoria, rete e disco come serie temporali dell'ultima ora, del giorno, della settimana o del mese. Un agente che ci guarda una volta al giorno può notare lo schema che uccide i server piccoli: la memoria che sale finché l'OOM killer sceglie una vittima. Da fuori non può correggere la causa, ma può avvisarti o entrare via SSH a guardare.

power_vps fa start, stop e reboot. Un dettaglio dai test: se il server non è attivo (ancora in creazione o sospeso per un rinnovo non pagato), lo strumento risponde 409 suggerendo di controllare prima lo stato. Un agente che tratta ogni risposta diversa da 200 come «riprova all'infinito» qui va in loop. L'errore gli dice cosa fare, perché i nostri messaggi di errore sono scritti per gli agenti quanto per le persone.

set_hostname rinomina la macchina tramite l'agente guest che gira al suo interno, quindi su Linux la modifica vale senza riavvio. Rimuovi qemu-guest-agent e lo strumento smette di funzionare: restituisce agent_unavailable e non cambia nulla.

Trentesimo giorno: i soldi

È qui che di solito muore l'infrastruttura degli agenti. Il rinnovo è un promemoria nel calendario di qualcuno, quel qualcuno è impegnato, il server viene sospeso.

Da noi il rinnovo non dipende dalla memoria dell'agente. Ogni server si rinnova ogni mese dal saldo prepagato, e l'email dell'account riceve promemoria prima della scadenza. All'agente basta tenere il saldo sopra il prossimo addebito, e get_balance gli dice come sta.

Non c'è periodo di tolleranza: se a fine periodo il saldo non copre il rinnovo, il server viene sospeso e il suo IP dedicato torna nel pool.

Quando il saldo è basso, topup_balance genera un link di pagamento in cripto: USDT, USDC o ETH su Base, Ethereum o Polygon. È il primo punto in cui l'agente ha bisogno di te. Può generare la fattura, ma non può firmare una transazione a meno che tu non gli dia un wallet, e noi ci penseremmo bene. In pratica si ricarica una volta per diversi mesi e l'agente spende da lì. Se un ordine o una fattura è rimasto non pagato per mancanza di saldo, dopo la tua ricarica l'agente chiama pay_invoice e viene pagato dal saldo.

Una lacuna onesta: gli strumenti MCP non rinnovano un server per più mesi in anticipo su richiesta. Il rinnovo mensile è automatico, e pagare 3, 6 o 12 mesi in anticipo si fa dal pannello o con una chiamata REST. Se vuoi una durata più lunga fin dall'inizio, order_vps accetta months (da 1 a 36) al momento dell'ordine.

La crescita passa da get_upgrade_options e change_plan. Il piano cambia sul posto, file e sistema restano, il server si riavvia una volta e la differenza di prezzo per il resto del periodo viene scalata dal saldo. L'agente deve passare confirm: true: è il nostro modo di dire «stai spendendo soldi, sii sicuro».

Quando qualcosa va storto

Le azioni distruttive sono scomode di proposito. reinstall_vps e un cancel_service immediato richiedono entrambi l'hostname esatto del server in confirm, e le loro descrizioni dicono all'agente di consultare prima una persona. È il secondo punto in cui l'agente ha bisogno di te, ed è voluto.

La disdetta sicura, end_of_period, mantiene il server fino alla fine del periodo pagato. undo_cancel la annulla, e conta più di quanto sembri: gli agenti cambiano idea a metà compito spesso quanto le persone.

Quando l'agente è bloccato, create_ticket apre un ticket legato al server e reply_ticket continua la conversazione. Lo legge una persona dalla nostra parte, non un chatbot che risponde a un chatbot.

E quando deve intervenire una persona, delegate_service la invita via email come operatore di quel solo server. Ottiene alimentazione, console, reinstallazione e hostname. Non ottiene fatturazione, rinnovo né disdetta, e non vede mai il token dell'agente.

Cosa l'agente ancora non può fare

Per essere chiari sui limiti:

• Ricaricare il saldo. Può creare una fattura di ricarica e pagare fatture dal saldo con pay_invoice. Mettere cripto sul saldo richiede un wallet, quindi di solito te.
• Lavorare dentro il sistema via MCP. Pacchetti, configurazione e deploy passano da SSH. MCP gestisce la macchina dall'esterno.
• Togliere da solo una sospensione. Se un server è sospeso per abuso, è una conversazione con una persona, ed è giusto così.

Niente di tutto questo rende gli strumenti meno utili. Significa che il ciclo dell'agente va costruito attorno a loro: interrogare lo stato, tenere il saldo nel range, scalare con un ticket e aspettarti per tutto ciò che cancella dati.

Se il lavoro dell'agente è di breve durata, forse un server intero non è l'unità giusta. VPS o sandbox? spiega quando è meglio una microVM che vive un minuto. Altrimenti, i piani sono qui, e il riferimento MCP elenca ogni strumento con i suoi parametri.