Depois do pedido: como um agente de IA cuida do próprio VPS via MCP

Quase todas as demos de um agente comprando um servidor terminam no momento em que o pedido é pago. É o momento menos interessante. O servidor existe, o agente tem um id como 47HZ7YF e ninguém disse o que vem depois.

Depois vem tudo o que um admin faz sem pensar: esperar o SSH responder de verdade, achar a senha, perceber que o disco está enchendo, reiniciar depois de atualizar o kernel, renovar antes de o mês acabar, chamar o suporte quando algo parece estranho. Se um agente vai ser dono de infraestrutura, essa parte também é dele. É assim que funciona com o nosso servidor MCP. Testamos cada passo no nosso ambiente de testes antes de escrever.

Se você ainda não conectou um cliente, comece por Claude Code e Codex ou Claude Desktop e Cursor.

Primeiro minuto: "active" não é "pronto"

order_vps responde assim que o pedido é pago com o saldo. O servidor é criado em segundo plano, normalmente em cerca de um minuto. A próxima chamada do agente é get_vps_status, e ele pode repeti-la à vontade: a ferramenta só lê.

Dois campos importam. status vira active quando a máquina existe. Em access está o que o agente precisa para entrar: host, porta e um comando SSH pronto. Nos planos com IPv4 própria a porta é 22. Nos planos NAT é uma porta encaminhada pessoal, e a resposta diz isso explicitamente, com o aviso de não se trancar do lado de fora com um firewall que só libera a porta externa.

Entre esses dois momentos há um intervalo em que muita gente tropeça. O primeiro boot instala atualizações do SO, o que pode levar alguns minutos, e o SSH pode recusar conexões nesse meio-tempo. Um agente cuidadoso espera access.ssh_ready em vez de martelar a porta 22.

Se o pedido não tinha chave SSH, a senha de root está esperando. reveal_password a entrega exatamente uma vez, e só depois que a VM terminou de iniciar. Pergunte cedo demais e você recebe password_pending sem gastar a exibição única. Fizemos assim depois que agentes pegavam uma senha que a VM, ainda iniciando, não tinha aplicado. Mas, sinceramente, passe uma ssh_key no pedido e pule essa etapa.

Segundo dia: de olho

get_vps_metrics retorna CPU, memória, rede e disco como séries temporais da última hora, dia, semana ou mês. Um agente que olha uma vez por dia consegue notar o padrão que mata servidores pequenos: memória subindo até o OOM killer escolher uma vítima. De fora ele não corrige a causa, mas pode avisar você ou entrar por SSH para olhar.

power_vps faz start, stop e reboot. Um detalhe dos testes: se o servidor não está ativo (ainda sendo criado ou suspenso por renovação não paga), a ferramenta responde 409 com a dica de verificar o status antes. Um agente que trata qualquer resposta diferente de 200 como "tentar de novo para sempre" vai ficar em loop aqui. O erro diz o que fazer, porque nossas mensagens de erro são escritas tanto para agentes quanto para pessoas.

set_hostname renomeia a máquina pelo agente convidado que roda dentro dela, então no Linux a mudança vale sem reiniciar. Remova o qemu-guest-agent e a ferramenta para de funcionar: retorna agent_unavailable e não muda nada.

Trigésimo dia: dinheiro

É aqui que a infraestrutura de agentes costuma morrer. A renovação fica no calendário de alguém, esse alguém está ocupado e o servidor é suspenso.

Aqui a renovação não depende da memória do agente. Cada servidor se renova todo mês pelo saldo pré-pago, e o e-mail da conta recebe lembretes antes da data. O agente só precisa manter o saldo acima da próxima cobrança, e get_balance mostra como está.

Não há período de carência: se no fim do prazo o saldo não cobrir a renovação, o servidor é suspenso e o IP dedicado volta para o pool.

Quando o saldo está baixo, topup_balance gera um link de pagamento em cripto: USDT, USDC ou ETH em Base, Ethereum ou Polygon. É o primeiro ponto em que o agente precisa de você. Ele gera a fatura, mas não assina uma transação a menos que você lhe dê uma carteira, e nós pensaríamos muito antes disso. Na prática, as pessoas recarregam uma vez para vários meses e deixam o agente gastar dali. Se um pedido ou fatura ficou sem pagamento porque faltou saldo, depois da sua recarga o agente chama pay_invoice e ela é paga com o saldo.

Uma lacuna honesta: as ferramentas MCP não renovam um servidor vários meses adiantados sob demanda. A renovação mensal é automática, e pagar 3, 6 ou 12 meses adiantados é feito no painel ou com uma chamada REST. Se quiser um prazo maior desde o início, order_vps aceita months (de 1 a 36) no pedido.

O crescimento fica com get_upgrade_options e change_plan. O plano muda no lugar, arquivos e SO continuam, o servidor reinicia uma vez e a diferença de preço pelo restante do período sai do saldo. O agente precisa passar confirm: true, que é o nosso jeito de dizer "você está gastando dinheiro, tenha certeza".

Quando algo dá errado

Ações destrutivas são incômodas de propósito. reinstall_vps e um cancel_service imediato exigem o hostname exato do servidor em confirm, e suas descrições mandam o agente consultar uma pessoa antes. Esse é o segundo ponto em que o agente precisa de você, e é intencional.

O cancelamento seguro, end_of_period, mantém o servidor até o fim do período pago. undo_cancel desfaz, e isso importa mais do que parece: agentes mudam de ideia no meio da tarefa tanto quanto pessoas.

Quando o agente trava, create_ticket abre um ticket ligado ao servidor e reply_ticket continua a conversa. Quem lê é uma pessoa do nosso lado, não um chatbot respondendo a outro chatbot.

E quando uma pessoa precisa entrar em cena, delegate_service a convida por e-mail como operadora daquele único servidor. Ela recebe energia, console, reinstalação e hostname. Não recebe faturamento, renovação nem cancelamento, e nunca vê o token do agente.

O que o agente ainda não consegue

Para deixar os limites claros:

• Carregar o saldo. Ele cria uma fatura de recarga e paga faturas com o saldo via pay_invoice. Colocar cripto no saldo exige uma carteira, ou seja, normalmente você.
• Trabalhar dentro do SO via MCP. Pacotes, configuração e deploys passam por SSH. O MCP gerencia a máquina por fora.
• Levantar uma suspensão sozinho. Se um servidor é suspenso por abuso, isso é uma conversa com uma pessoa, e deve ser assim.

Nada disso torna as ferramentas menos úteis. Significa que o loop do agente deve ser desenhado em torno delas: consultar o status, manter o saldo na faixa certa, escalar por ticket e esperar você antes de qualquer coisa que apague dados.

Se o trabalho do agente é de curta duração, talvez um servidor inteiro não seja a unidade certa. VPS ou sandbox? explica quando uma microVM que vive um minuto se encaixa melhor. Caso contrário, os planos estão aqui, e a referência do MCP lista cada ferramenta com seus parâmetros.