După comandă: cum își administrează un agent AI propriul VPS prin MCP

Majoritatea demonstrațiilor în care un agent cumpără un server se opresc în momentul în care comanda trece. E momentul cel mai puțin interesant. Serverul există, agentul are un id de tipul 47HZ7YF și nimeni n-a spus ce urmează.

Urmează tot ce face un administrator fără să se gândească: să aștepte până când SSH chiar răspunde, să găsească parola, să observe că discul se umple, să repornească după o actualizare de kernel, să reînnoiască înainte să se termine luna, să întrebe suportul când ceva pare ciudat. Dacă un agent va deține infrastructură, partea asta e tot a lui. Iată cum merge prin serverul nostru MCP. Am rulat fiecare pas în mediul nostru de test înainte să-l descriem.

Dacă n-ai conectat încă un client, începe cu Claude Code și Codex sau cu Claude Desktop și Cursor.

Primul minut: „active” nu înseamnă „gata”

order_vps răspunde imediat ce comanda e plătită din sold. Serverul se creează în fundal, de obicei în aproximativ un minut. Următorul apel al agentului e get_vps_status, pe care îl poate repeta oricât: unealta doar citește.

Contează două câmpuri. status devine active când mașina există. În access se află tot ce-i trebuie agentului ca să intre: host, port și o comandă SSH gata făcută. La planurile cu IPv4 propriu portul e 22. La planurile NAT e un port redirecționat personal, iar răspunsul o spune explicit, inclusiv cu avertismentul să nu te închizi afară cu un firewall care permite doar portul exterior.

Între aceste două momente e o gaură în care se împiedică lumea. Prima pornire instalează actualizările sistemului, ceea ce poate dura câteva minute, iar SSH poate refuza conexiuni între timp. Un agent atent așteaptă access.ssh_ready în loc să bată în portul 22.

Dacă la comandă nu s-a dat o cheie SSH, te așteaptă parola de root. reveal_password o dă exact o dată și numai după ce VM-ul a terminat de pornit. Dacă întrebi prea devreme, primești password_pending fără să consumi afișarea unică. Am făcut așa după ce agenții luau mereu o parolă pe care VM-ul, încă pornind, n-o aplicase. Sincer însă: dă o ssh_key la comandă și sari peste pasul ăsta.

Ziua a doua: supravegherea

get_vps_metrics returnează CPU, memorie, rețea și disc ca serii de timp pentru ultima oră, zi, săptămână sau lună. Un agent care se uită o dată pe zi poate observa tiparul care omoară serverele mici: memoria care urcă până când OOM killer alege o victimă. Din exterior nu poate repara cauza, dar îți poate spune sau poate intra prin SSH să se uite.

power_vps face start, stop și reboot. Un detaliu din teste: dacă serverul nu e activ (încă se creează sau e suspendat pentru o reînnoire neplătită), unealta răspunde cu 409 și sfatul de a verifica mai întâi starea. Un agent care tratează orice răspuns diferit de 200 ca „reîncearcă la nesfârșit” se va bucla aici. Eroarea îi spune ce să facă, pentru că mesajele noastre de eroare sunt scrise la fel de mult pentru agenți ca pentru oameni.

set_hostname redenumește mașina prin agentul invitat care rulează în ea, așa că pe Linux schimbarea se aplică fără repornire. Scoate qemu-guest-agent și unealta nu mai funcționează: returnează agent_unavailable și nu schimbă nimic.

Ziua a treizecea: banii

Aici moare de obicei infrastructura agenților. Reînnoirea e un memento în calendarul cuiva, acel cineva e ocupat, serverul e suspendat.

La noi reînnoirea nu depinde de memoria agentului. Fiecare server se reînnoiește lunar din soldul preplătit, iar e-mailul contului primește mementouri înainte de dată. Agentul trebuie doar să țină soldul peste următoarea debitare, iar get_balance îi arată cum stă.

Nu există perioadă de grație: dacă la sfârșitul perioadei soldul nu acoperă reînnoirea, serverul e suspendat, iar IP-ul său dedicat se întoarce în pool.

Când soldul e mic, topup_balance generează un link de plată cripto: USDT, USDC sau ETH pe Base, Ethereum sau Polygon. E primul loc în care agentul are nevoie de tine. Poate genera factura, dar nu poate semna o tranzacție decât dacă i-ai dat un portofel, iar noi ne-am gândi bine înainte. În practică, oamenii alimentează o dată pentru câteva luni și lasă agentul să cheltuiască de acolo. Dacă o comandă sau o factură a rămas neplătită pentru că soldul n-a ajuns, după alimentarea ta agentul apelează pay_invoice și e plătită din sold.

O lipsă onestă: uneltele MCP nu reînnoiesc un server pe mai multe luni înainte, la cerere. Reînnoirea lunară e automată, iar plata pe 3, 6 sau 12 luni în avans se face din panou sau cu un apel REST. Dacă vrei o perioadă mai lungă de la început, order_vps acceptă months (de la 1 la 36) la comandă.

Creșterea o acoperă get_upgrade_options și change_plan. Planul se schimbă pe loc, fișierele și sistemul rămân, serverul repornește o dată, iar diferența de preț pentru restul perioadei se scade din sold. Agentul trebuie să trimită confirm: true — felul nostru de a spune „cheltui bani, fii sigur”.

Când ceva merge prost

Acțiunile distructive sunt incomode intenționat. reinstall_vps și un cancel_service imediat cer amândouă hostname-ul exact al serverului în confirm, iar descrierile lor îi spun agentului să consulte mai întâi un om. E al doilea loc în care agentul are nevoie de tine, și e intenționat.

Rezilierea sigură, end_of_period, păstrează serverul până se termină perioada plătită. undo_cancel o anulează, și asta contează mai mult decât ai crede: agenții se răzgândesc la mijlocul unei sarcini la fel de des ca oamenii.

Când agentul se blochează, create_ticket deschide un tichet legat de server, iar reply_ticket continuă discuția. Îl citește un om de la noi, nu un chatbot care răspunde unui chatbot.

Iar când trebuie să intervină un om, delegate_service îl invită prin e-mail ca operator al acelui singur server. Primește alimentare, consolă, reinstalare și hostname. Nu primește facturare, reînnoire sau reziliere și nu vede niciodată tokenul agentului.

Ce încă nu poate face agentul

Ca să fie clare limitele:

• Să alimenteze soldul. Poate crea o factură de alimentare și poate plăti facturi din sold cu pay_invoice. Ca să pui cripto în sold e nevoie de un portofel, adică de obicei de tine.
• Să lucreze în sistemul de operare prin MCP. Pachetele, configurarea și deployurile trec prin SSH. MCP gestionează mașina din exterior.
• Să ridice singur o suspendare. Dacă un server e suspendat pentru abuz, asta e o discuție cu un om, și așa trebuie să fie.

Nimic din toate acestea nu face uneltele mai puțin utile. Înseamnă doar că bucla agentului trebuie construită în jurul lor: interoghează starea, ține soldul în limite, escaladează printr-un tichet și te așteaptă înainte de orice șterge date.

Dacă munca agentului e de scurtă durată, poate un server întreg nu e unitatea potrivită. VPS sau sandbox? explică când se potrivește mai bine o microVM care trăiește un minut. Altfel, planurile sunt aici, iar referința MCP listează fiecare unealtă cu parametrii ei.