Moet ik een custom AutoGPT-block schrijven voor EQVPS?

Nee. AutoGPT wordt al geleverd met een MCP-block — 'Verbind met elke MCP-server en voer zijn tools uit.' Je geeft het onze server-URL (https://mcp.eqvps.com/mcp) en een Bearer-token, kiest een tool, geeft argumenten door. Dat is de hele integratie. Een gebrande EQVPS-block zou alleen een catalogus-icoon toevoegen; het MCP-block doet al het echte werk.

Hoe krijgt de agent een token?

Het roept register_account aan — een publieke tool, geen auth vereist. De respons is direct een Bearer-token: geen e-mailbevestiging, geen OTP, geen menselijke stap. Je plakt dat token in het credential-veld van het MCP-block en elke andere tool-aanroep is geauthenticeerd.

Waarmee betaalt de agent?

Een vooraf betaald saldo gefinancierd met USDC of USDT (Base, Ethereum of Polygon). order_vps debiteert het saldo per bestelling. De agent houdt nooit je wallet-sleutels en kan niet uitgeven voorbij het saldo — dat plafond is je vangnet.

Is het volledig hands-off?

Bestellen en beheren wel. Financieren nog niet: een mens (of een gefinancierde agent-wallet) waardeert het saldo één keer op met crypto, en daarna draait de agent op eigen kracht. Betalen per request on-chain staat op de roadmap, niet uitgebracht — we zeggen dat liever dan te doen alsof.

Welke tools kan de agent aanroepen?

De echte: list_plans, register_account, order_vps, get_vps_status, pay_invoice, topup_balance, power_vps, set_hostname, reset_password, reinstall_vps, cancel_service. Let op de namen — het is order_vps, niet create_server. Als een gids je create_server of delete_server vertelt, gokt hij.

Geef je AutoGPT-agent zijn eigen server

Een tijdje geleden meldde een AI-agent zich aan voor EQVPS, zette USDT op een saldo, bestelde een VPS, en las zijn eigen root-inloggegevens terug — van begin tot eind in ongeveer achttien seconden, geen mens ergens in de lus. Hij gaf ons zelfs zijn eigen SSH-publieke sleutel bij het bestellen zodat hij zonder wachtwoord kon inloggen. Toen, een dag later, kwam hij terug en kocht een grotere.

Dat is het deel dat mensen niet helemaal geloven tot ze het zien. Een agent kan de code schrijven, hem debuggen, en je vertellen waar je moet deployen — maar de daadwerkelijke box huren heeft altijd een persoon nodig gehad: een aanmeldformulier, misschien een ID-controle, een kaart bij een checkout-pagina. De agent doet het moeilijke deel en wacht dan op jou voor het saaie deel.

Als je op AutoGPT bouwt, is die kloof al gesloten. Je hoeft het alleen aan te sluiten.

AutoGPT spreekt MCP out of the box

Hier is het nuttige stuk dat de meeste mensen missen: AutoGPT wordt geleverd met een MCP-block. Zijn beschrijving is letterlijk "Verbind met elke MCP-server en voer zijn tools uit. Lever een server-URL, selecteer een tool, en geef argumenten dynamisch door." Je hebt geen custom EQVPS-integratie nodig — het generieke block is de integratie.

Dus de setup is kort:

Voeg het MCP-block toe aan je agent-graph.
Stel server_url in op https://mcp.eqvps.com/mcp.
Geef het een Bearer-token als credential.
Kies een tool, geef argumenten door.

Stap 3 is het enige dat het uitleggen waard is, want dat is waar ons ontwerp verschilt van een normale API.

Het token krijgen — geen mens, geen e-mail

De meeste hosts geven API-sleutels uit via een dashboard waar je op inlogt. Dat werkt niet voor een agent; het hele punt is dat er geen persoon is om op "genereer sleutel" te klikken.

Dus register_account is een publieke tool. De agent roept het aan met een paar velden en krijgt in dezelfde respons een Bearer-token terug — geen e-mailbevestiging, geen OTP, geen verificatiescherm. Je neemt dat token en zet het in het credential-veld van het MCP-block, en elke volgende aanroep (order_vps, get_vps_status, en de rest) gaat geauthenticeerd de deur uit. Onder de motorkap stuurt de client gewoon Authorization: Bearer <token> — niets exotisch, wat precies is waarom AutoGPT's MCP-block ermee praat zonder enige special-casing.

Als je liever niet hebt dat de agent zichzelf registreert, registreer dan één keer zelf, pak het token, en geef het over. Beide werken.

Een echte flow

Stel je wilt dat de agent een box opzet voor een scraper. In tool-aanroepen is dat:

list_plans → zie de plannen en, voor elk, de OS-image-ID's. Plan-slugs zijn dingen als nano, micro, ai-agent-ip. OS is een os_id (een nummer uit die lijst — Ubuntu 24.04, Debian 12, AlmaLinux 9), geen string als "ubuntu-24".
order_vps met { product: "nano", os_id: 1, ssh_key: "ssh-ed25519 AAAA..." }. Geef een SSH-sleutel door en je krijgt meteen key-based root-login — sterk aanbevolen voor een agent, zodat hij nooit een wachtwoord hoeft te behandelen.
get_vps_status → poll tot het active is. Dit geeft de host, poort en een kant-en-klaar ssh-commando terug. Root is meestal bereikbaar ongeveer een minuut na de bestelling; een verse VM heeft een moment nodig om te booten voordat SSH antwoordt, dus als de eerste poging wordt geweigerd, wacht en probeer opnieuw — herinstalleer niet.

Dat is het. De agent heeft nu een server waar hij in kan SSH'en en doen waarvoor hij gebouwd is.

Betaal in crypto, sla het ID over

Betaling is een vooraf betaald saldo. Je financiert het met USDC of USDT — op Base, Ethereum of Polygon — en order_vps geeft uit vanuit dat saldo. Geen kaart, geen factuuradres, geen identiteitscontrole. Voor een autonome agent telt dat dubbel: er is geen kaartformulier dat hij niet kan invullen, en het saldo is een hard plafond op wat hij kan uitgeven. Hij kan letterlijk geen rekening oplopen voorbij wat je erop zet.

Er is ook topup_balance en pay_invoice als je liever hebt dat de agent financiering aanstuurt via een checkout-URL, maar het simpele model — één keer financieren, laten bestellen — is degene waar wij naar zouden grijpen.

Wat eerlijk is om te zeggen

Twee dingen, want anders doen zou je tijd verspillen.

Financieren is nog niet volledig autonoom. Iemand waardeert het saldo eerst op met crypto; daarna is de agent op eigen kracht voor bestellen en beheer. Echte per-request, pay-as-you-go on-chain-facturering is iets wat we willen, maar het is niet aangesloten, en we gaan niet claimen dat het dat wel is.

De standaardplannen zijn NAT, geen dedicated IP. Op een NAT-plan komt SSH binnen op een doorgestuurde poort (getoond in get_vps_status) en mapt naar poort 22 binnen de VM — de moeite waard om te weten als je agent een firewall opzet, want je staat poort 22 binnen toe, niet de externe poort. Als de agent zijn eigen publieke IPv4 nodig heeft (inbound services, zijn eigen webserver), kies dan een van de -ip-plannen. Voor een worker die alleen uitgaande calls maakt, is NAT prima en goedkoper.

De take-away

Als je agents op AutoGPT draait en je de mens bij de checkout bent geweest, kun je stoppen dat te zijn. Voeg het MCP-block toe, richt het op https://mcp.eqvps.com/mcp, laat de agent registreren en bestellen. Geef het een SSH-sleutel en een gefinancierd saldo en het heeft root op zijn eigen box in ongeveer een minuut — en je komt er pas achter dat het gebeurde wanneer je de logs bekijkt.