Dois-je écrire un bloc AutoGPT personnalisé pour EQVPS ?

Non. AutoGPT est déjà livré avec un bloc MCP — « Connectez-vous à n'importe quel serveur MCP et exécutez ses outils. » Vous lui donnez l'URL de notre serveur (https://mcp.eqvps.com/mcp) et un jeton Bearer, choisissez un outil, passez des arguments. C'est toute l'intégration. Un bloc EQVPS de marque n'ajouterait qu'une icône de catalogue ; le bloc MCP fait déjà le vrai travail.

Comment l'agent obtient-il un jeton ?

Il appelle register_account — un outil public, sans authentification requise. La réponse est un jeton Bearer immédiatement : pas de confirmation e-mail, pas d'OTP, pas d'étape humaine. Vous collez ce jeton dans le champ d'identifiants du bloc MCP et chaque autre appel d'outil est authentifié.

Avec quoi l'agent paie-t-il ?

Un solde prépayé alimenté avec USDC ou USDT (Base, Ethereum ou Polygon). order_vps débite le solde par commande. L'agent ne détient jamais les clés de votre portefeuille et ne peut pas dépenser au-delà du solde — ce plafond est votre filet de sécurité.

Est-ce entièrement sans intervention ?

La commande et la gestion le sont. L'alimentation ne l'est pas encore : un humain (ou un portefeuille d'agent alimenté) recharge le solde en crypto une fois, et après ça l'agent tourne tout seul. Le paiement on-chain par requête est sur la feuille de route, pas livré — on préfère le dire que de faire semblant.

Quels outils l'agent peut-il appeler ?

Les vrais : list_plans, register_account, order_vps, get_vps_status, pay_invoice, topup_balance, power_vps, set_hostname, reset_password, reinstall_vps, cancel_service. Notez les noms — c'est order_vps, pas create_server. Si un guide vous dit create_server ou delete_server, il devine.

Donnez son propre serveur à votre agent AutoGPT

Il y a quelque temps, un agent IA s'est inscrit chez EQVPS, a mis de l'USDT sur un solde, a commandé un VPS, et s'est relu ses propres identifiants root — du début à la fin en dix-huit secondes environ, sans humain nulle part dans la boucle. Il nous a même remis sa propre clé publique SSH au moment de la commande pour pouvoir se connecter sans mot de passe. Puis, un jour plus tard, il est revenu en acheter un plus gros.

C'est la partie que les gens ont du mal à croire avant de la voir. Un agent peut écrire le code, le déboguer, et vous dire où le déployer — mais louer la machine elle-même a toujours nécessité une personne : un formulaire d'inscription, peut-être une vérification d'identité, une carte sur une page de paiement. L'agent fait la partie difficile puis vous attend pour la partie ennuyeuse.

Si vous construisez sur AutoGPT, cet écart est déjà comblé. Il vous suffit de le câbler.

AutoGPT parle MCP nativement

Voici le point utile que la plupart des gens ratent : AutoGPT est livré avec un bloc MCP. Sa description est littéralement « Connectez-vous à n'importe quel serveur MCP et exécutez ses outils. Fournissez une URL de serveur, sélectionnez un outil, et passez des arguments dynamiquement. » Vous n'avez pas besoin d'une intégration EQVPS personnalisée — le bloc générique est l'intégration.

Donc l'installation est courte :

Ajoutez le bloc MCP à votre graphe d'agent.
Réglez server_url sur https://mcp.eqvps.com/mcp.
Donnez-lui un jeton Bearer comme identifiant.
Choisissez un outil, passez des arguments.

L'étape 3 est la seule qui vaille une explication, parce que c'est là que notre conception diffère d'une API normale.

Obtenir le jeton — pas d'humain, pas d'e-mail

La plupart des hébergeurs distribuent des clés API via un tableau de bord auquel vous vous connectez. Ça ne marche pas pour un agent ; tout l'intérêt, c'est qu'il n'y a pas de personne pour cliquer sur « générer la clé ».

Donc register_account est un outil public. L'agent l'appelle avec quelques champs et récupère un jeton Bearer dans la même réponse — pas de confirmation e-mail, pas d'OTP, pas d'écran de vérification. Vous prenez ce jeton et le déposez dans le champ d'identifiants du bloc MCP, et chaque appel suivant (order_vps, get_vps_status, et le reste) part authentifié. Sous le capot, le client envoie juste Authorization: Bearer <token> — rien d'exotique, ce qui est exactement pourquoi le bloc MCP d'AutoGPT lui parle sans traitement particulier.

Si vous préférez que l'agent ne s'inscrive pas lui-même, inscrivez-vous une fois vous-même, prenez le jeton, et remettez-le-lui. Les deux marchent.

Un vrai flux

Disons que vous voulez que l'agent monte une machine pour un scraper. En appels d'outils, ça donne :

list_plans → voir les plans et, pour chacun, les ID d'images OS. Les slugs de plans sont des choses comme nano, micro, ai-agent-ip. L'OS est un os_id (un nombre de cette liste — Ubuntu 24.04, Debian 12, AlmaLinux 9), pas une chaîne comme "ubuntu-24".
order_vps avec { product: "nano", os_id: 1, ssh_key: "ssh-ed25519 AAAA..." }. Passez une clé SSH et vous obtenez une connexion root par clé tout de suite — fortement recommandé pour un agent, pour qu'il n'ait jamais à gérer de mot de passe.
get_vps_status → interrogez jusqu'à ce qu'il soit active. Ça renvoie l'hôte, le port et une commande ssh prête à coller. Root est généralement joignable environ une minute après la commande ; une VM fraîche a besoin d'un moment pour démarrer avant que le SSH réponde, donc si la première tentative est refusée, attendez et réessayez — ne réinstallez pas.

Voilà. L'agent a maintenant un serveur dans lequel il peut se connecter en SSH et faire tout ce pour quoi il a été construit.

Payez en crypto, sautez la pièce d'identité

Le paiement est un solde prépayé. Vous l'alimentez avec USDC ou USDT — sur Base, Ethereum ou Polygon — et order_vps dépense depuis ce solde. Pas de carte, pas d'adresse de facturation, pas de vérification d'identité. Pour un agent autonome, ça compte doublement : il n'y a pas de formulaire de carte qu'il ne peut pas remplir, et le solde est un plafond dur sur ce qu'il peut dépenser. Il ne peut littéralement pas accumuler une facture au-delà de ce que vous y mettez.

Il y a aussi topup_balance et pay_invoice si vous préférez que l'agent pilote l'alimentation via une URL de paiement, mais le modèle simple — alimenter une fois, le laisser commander — est celui vers lequel nous nous tournerions.

Ce qu'il est honnête de dire

Deux choses, parce que prétendre le contraire vous ferait perdre du temps.

L'alimentation n'est pas encore entièrement autonome. Quelqu'un recharge le solde en crypto d'abord ; après ça, l'agent est seul pour la commande et la gestion. Une vraie facturation on-chain par requête, à l'usage, c'est quelque chose que nous voulons, mais ce n'est pas câblé, et nous n'allons pas prétendre que ça l'est.

Les plans par défaut sont NAT, pas une IP dédiée. Sur un plan NAT, le SSH arrive sur un port redirigé (montré dans get_vps_status) et mappe vers le port 22 à l'intérieur de la VM — bon à savoir si votre agent met en place un pare-feu, parce que vous autorisez le port 22 à l'intérieur, pas le port externe. Si l'agent a besoin de sa propre IPv4 publique (services entrants, son propre serveur web), choisissez plutôt un des plans -ip. Pour un worker qui ne fait que des appels sortants, NAT convient et coûte moins cher.

À retenir

Si vous faites tourner des agents sur AutoGPT et que vous avez été l'humain à la caisse, vous pouvez cesser de l'être. Ajoutez le bloc MCP, pointez-le sur https://mcp.eqvps.com/mcp, laissez l'agent s'inscrire et commander. Donnez-lui une clé SSH et un solde alimenté et il aura root sur sa propre machine en une minute environ — et vous ne l'apprendrez qu'en vérifiant les logs.