Måste jag skriva ett custom AutoGPT-block för EQVPS?

Nej. AutoGPT levereras redan med ett MCP-block — 'Anslut till vilken MCP-server som helst och kör dess verktyg.' Du ger det vår server-URL (https://mcp.eqvps.com/mcp) och en Bearer-token, väljer ett verktyg, skickar argument. Det är hela integrationen. Ett brandat EQVPS-block skulle bara lägga till en katalog-ikon; MCP-blocket gör redan det faktiska arbetet.

Hur får agenten en token?

Den anropar register_account — ett publikt verktyg, ingen auth krävs. Svaret är en Bearer-token direkt: ingen e-postbekräftelse, ingen OTP, inget mänskligt steg. Du klistrar in den token i MCP-blockets credential-fält och varje annat verktygsanrop är autentiserat.

Vad betalar agenten med?

Ett förbetalt saldo finansierat med USDC eller USDT (Base, Ethereum eller Polygon). order_vps debiterar saldot per beställning. Agenten håller aldrig dina plånboksnycklar och kan inte spendera bortom saldot — det taket är ditt skyddsnät.

Är det helt hands-off?

Beställning och hantering är det. Finansiering är inte det ännu: en människa (eller en finansierad agent-plånbok) fyller på saldot en gång med krypto, och efter det körs agenten på egen hand. Betalning per request on-chain finns på roadmapen, inte levererat — vi säger det hellre än låtsas.

Vilka verktyg kan agenten anropa?

De riktiga: list_plans, register_account, order_vps, get_vps_status, pay_invoice, topup_balance, power_vps, set_hostname, reset_password, reinstall_vps, cancel_service. Notera namnen — det är order_vps, inte create_server. Om en guide säger create_server eller delete_server, gissar den.

Ge din AutoGPT-agent sin egen server

För ett tag sedan registrerade sig en AI-agent för EQVPS, satte USDT på ett saldo, beställde en VPS, och läste tillbaka sina egna root-uppgifter — från början till slut på ungefär arton sekunder, ingen människa någonstans i loopen. Den lämnade till och med över sin egen SSH-publika nyckel vid beställningen så att den kunde logga in utan lösenord. Sedan, en dag senare, kom den tillbaka och köpte en större.

Det är delen folk inte riktigt tror förrän de ser den. En agent kan skriva koden, felsöka den, och tala om för dig var du ska distribuera — men att hyra den faktiska boxen har alltid behövt en person: ett registreringsformulär, kanske en ID-kontroll, ett kort vid en kassasida. Agenten gör det svåra och väntar sedan på dig för den tråkiga delen.

Om du bygger på AutoGPT är den klyftan redan sluten. Du behöver bara koppla upp det.

AutoGPT talar MCP direkt

Här är den användbara biten de flesta missar: AutoGPT levereras med ett MCP-block. Dess beskrivning är bokstavligen "Anslut till vilken MCP-server som helst och kör dess verktyg. Tillhandahåll en server-URL, välj ett verktyg, och skicka argument dynamiskt." Du behöver ingen custom EQVPS-integration — det generiska blocket är integrationen.

Så uppsättningen är kort:

Lägg till MCP-blocket i din agent-graf.
Ställ in server_url till https://mcp.eqvps.com/mcp.
Ge det en Bearer-token som credential.
Välj ett verktyg, skicka argument.

Steg 3 är det enda värt att förklara, för det är där vår design skiljer sig från en normal API.

Att få token — ingen människa, ingen e-post

De flesta hostar delar ut API-nycklar genom en dashboard du loggar in på. Det fungerar inte för en agent; hela poängen är att det inte finns någon person att klicka "generera nyckel."

Så register_account är ett publikt verktyg. Agenten anropar det med ett par fält och får en Bearer-token tillbaka i samma svar — ingen e-postbekräftelse, ingen OTP, ingen verifieringsskärm. Du tar den token och släpper den i MCP-blockets credential-fält, och varje efterföljande anrop (order_vps, get_vps_status, och resten) går ut autentiserat. Under huven skickar klienten bara Authorization: Bearer <token> — inget exotiskt, vilket är precis varför AutoGPT:s MCP-block pratar med det utan någon special-casing.

Om du hellre inte vill att agenten registrerar sig själv, registrera en gång själv, ta token, och lämna över den. Båda fungerar.

Ett riktigt flöde

Säg att du vill att agenten ska starta upp en box för en scraper. I verktygsanrop är det:

list_plans → se planerna och, för var och en, OS-image-ID:na. Plan-slugs är saker som nano, micro, ai-agent-ip. OS är ett os_id (ett nummer från den listan — Ubuntu 24.04, Debian 12, AlmaLinux 9), inte en sträng som "ubuntu-24".
order_vps med { product: "nano", os_id: 1, ssh_key: "ssh-ed25519 AAAA..." }. Skicka en SSH-nyckel och du får key-based root-inloggning direkt — starkt rekommenderat för en agent, så den aldrig behöver hantera ett lösenord.
get_vps_status → polla tills den är active. Detta returnerar host, port och ett redo-att-klistra ssh-kommando. Root är oftast nåbar ungefär en minut efter beställningen; en fräsch VM behöver ett ögonblick att boota innan SSH svarar, så om det första försöket avvisas, vänta och försök igen — ominstallera inte.

Det är det. Agenten har nu en server den kan SSH:a in i och göra vad den än byggdes för att göra.

Betala i krypto, hoppa över ID:t

Betalning är ett förbetalt saldo. Du finansierar det med USDC eller USDT — på Base, Ethereum eller Polygon — och order_vps spenderar från det saldot. Inget kort, ingen faktureringsadress, ingen identitetskontroll. För en autonom agent spelar det roll dubbelt upp: det finns inget kortformulär den inte kan fylla i, och saldot är ett hårt tak på vad den kan spendera. Den kan bokstavligen inte dra upp en räkning bortom vad du lägger på den.

Det finns också topup_balance och pay_invoice om du hellre vill att agenten driver finansiering genom en checkout-URL, men den enkla modellen — finansiera en gång, låt den beställa — är den vi skulle sträcka oss efter.

Vad som är ärligt att säga

Två saker, för att låtsas annat skulle slösa din tid.

Finansiering är inte helt autonom ännu. Någon fyller på saldot med krypto först; efter det är agenten på egen hand för beställning och hantering. Verklig per-request, pay-as-you-go on-chain-fakturering är något vi vill ha, men det är inte inkopplat, och vi tänker inte hävda att det är det.

Standardplanerna är NAT, inte en dedikerad IP. På ett NAT-plan kommer SSH in på en vidarebefordrad port (visad i get_vps_status) och mappar till port 22 inuti VM:en — värt att veta om din agent sätter upp en brandvägg, för du tillåter port 22 inuti, inte den externa porten. Om agenten behöver sin egen publika IPv4 (inbound-tjänster, sin egen webbserver), välj ett av -ip-planen istället. För en worker som bara gör utgående anrop är NAT bra och billigare.

Slutsatsen

Om du kör agenter på AutoGPT och du har varit människan vid kassan kan du sluta vara det. Lägg till MCP-blocket, rikta det mot https://mcp.eqvps.com/mcp, låt agenten registrera och beställa. Ge den en SSH-nyckel och ett finansierat saldo och den har root på sin egen box på ungefär en minut — och du får bara reda på att det hände när du kollar loggarna.