Después del pedido: cómo un agente de IA gestiona su propio VPS por MCP

Casi todas las demos en las que un agente compra un servidor terminan en el momento en que se paga el pedido. Es el momento menos interesante. El servidor existe, el agente tiene un id como 47HZ7YF y nadie ha dicho qué viene después.

Después viene todo lo que un administrador hace sin pensar: esperar a que SSH responda de verdad, encontrar la contraseña, darse cuenta de que el disco se llena, reiniciar tras una actualización del kernel, renovar antes de que acabe el mes, preguntar al soporte cuando algo parece raro. Si un agente va a ser dueño de infraestructura, también tiene que encargarse de eso. Así se hace con nuestro servidor MCP. Probamos cada paso en nuestro entorno de pruebas antes de escribirlo.

Si aún no has conectado un cliente, empieza por Claude Code y Codex o por Claude Desktop y Cursor.

Minuto uno: «active» no es «listo»

order_vps responde en cuanto el pedido se paga con el saldo. El servidor se crea en segundo plano, normalmente en un minuto aproximadamente. La siguiente llamada del agente es get_vps_status, y conviene repetirla: la herramienta solo lee y se puede consultar todas las veces que haga falta.

Importan dos campos. status pasa a active cuando la máquina existe. access contiene lo que el agente necesita para entrar: host, puerto y un comando SSH listo. En los planes con IPv4 propia el puerto es 22. En los planes NAT es un puerto reenviado personal, y la respuesta lo dice explícitamente, con un aviso para no bloquearte con un firewall que solo permita el puerto exterior.

Entre esos dos momentos hay un hueco en el que se tropieza. El primer arranque instala actualizaciones del SO, lo que puede tardar unos minutos, y SSH puede rechazar conexiones mientras tanto. Un agente cuidadoso espera a access.ssh_ready en lugar de aporrear el puerto 22.

Si el pedido no llevaba clave SSH, te espera la contraseña de root. reveal_password la entrega exactamente una vez y solo cuando la VM terminó de arrancar. Si preguntas antes, recibes password_pending sin gastar la revelación única. Lo hicimos así después de que los agentes se llevaran una y otra vez una contraseña que la VM, aún arrancando, no había aplicado. Pero, sinceramente, pasa una ssh_key en el pedido y sáltate este paso.

Día dos: vigilarlo

get_vps_metrics devuelve CPU, memoria, red y disco como series temporales de la última hora, día, semana o mes. Un agente que lo mira una vez al día puede detectar el patrón que mata a los servidores pequeños: la memoria subiendo hasta que el OOM killer elige una víctima. Desde fuera no puede arreglar la causa, pero puede avisarte o entrar por SSH a mirar.

power_vps hace start, stop y reboot. Un detalle de las pruebas: si el servidor no está activo (todavía se está creando o está suspendido por una renovación impagada), la herramienta devuelve un 409 con la indicación de comprobar primero el estado. Un agente que trata cualquier respuesta distinta de 200 como «reintentar para siempre» se quedará en bucle aquí. El error le dice qué hacer, porque nuestros mensajes de error están escritos tanto para agentes como para personas.

set_hostname renombra la máquina a través del agente invitado que corre dentro, así que en Linux el cambio se aplica sin reiniciar. Si quitas qemu-guest-agent, la herramienta deja de funcionar: devuelve agent_unavailable y no cambia nada.

Día treinta: dinero

Aquí es donde suele morir la infraestructura de los agentes. La renovación vive en el calendario de alguien, ese alguien está ocupado y el servidor se suspende.

Aquí la renovación no depende de la memoria del agente. Cada servidor se renueva cada mes desde el saldo prepago, y el correo de la cuenta recibe recordatorios antes de la fecha. Al agente le basta con mantener el saldo por encima del próximo cargo, y get_balance le dice cómo va.

No hay periodo de gracia: si al final del plazo el saldo no cubre la renovación, el servidor se suspende y su IP dedicada vuelve al pool.

Cuando el saldo es bajo, topup_balance genera un enlace de pago en cripto: USDT, USDC o ETH en Base, Ethereum o Polygon. Este es el primer punto en el que el agente te necesita. Puede generar la factura, pero no puede firmar una transacción salvo que le des una wallet, y eso nos lo pensaríamos mucho. En la práctica se recarga una vez para varios meses y el agente gasta de ahí. Si un pedido o una factura quedó sin pagar porque faltaba saldo, tras tu recarga el agente llama a pay_invoice y se paga con el saldo.

Un hueco honesto: las herramientas MCP no renuevan un servidor varios meses por adelantado bajo demanda. La renovación mensual es automática, y pagar 3, 6 o 12 meses por adelantado se hace en el panel o con una llamada REST. Si quieres un plazo más largo desde el principio, order_vps acepta months (de 1 a 36) al hacer el pedido.

El crecimiento lo cubren get_upgrade_options y change_plan. El plan cambia en el sitio, los archivos y el SO se mantienen, el servidor se reinicia una vez y la diferencia de precio del resto del periodo se descuenta del saldo. El agente tiene que pasar confirm: true, que es nuestra manera de decir «estás gastando dinero, asegúrate».

Cuando algo sale mal

Las acciones destructivas son incómodas a propósito. reinstall_vps y un cancel_service inmediato exigen el hostname exacto del servidor en confirm, y sus descripciones piden al agente que consulte antes con una persona. Ese es el segundo punto en el que el agente te necesita, y es intencionado.

La cancelación segura, end_of_period, mantiene el servidor hasta que se acaba el tiempo pagado. undo_cancel la revierte, y eso importa más de lo que parece: los agentes cambian de opinión a mitad de tarea tan a menudo como las personas.

Cuando el agente se atasca, create_ticket abre un ticket ligado al servidor y reply_ticket continúa la conversación. Lo lee una persona de nuestro equipo, no un chatbot respondiendo a otro chatbot.

Y cuando tiene que intervenir una persona, delegate_service la invita por correo como operadora de ese único servidor. Obtiene encendido, consola, reinstalación y hostname. No obtiene facturación, renovación ni cancelación, y nunca ve el token del agente.

Lo que el agente todavía no puede hacer

Para que quede claro:

• Recargar el saldo. Puede crear una factura de recarga y pagar facturas con el saldo mediante pay_invoice. Meter cripto en el saldo requiere una wallet, y eso normalmente eres tú.
• Trabajar dentro del SO por MCP. Paquetes, configuración y despliegues van por SSH. MCP gestiona la máquina desde fuera.
• Levantar una suspensión por su cuenta. Si un servidor se suspende por abuso, eso es una conversación con una persona, y así debe ser.

Nada de eso resta utilidad a las herramientas. Significa que conviene diseñar el bucle del agente alrededor de ellas: consultar el estado, mantener el saldo en rango, escalar mediante un ticket y esperarte antes de cualquier cosa que borre datos.

Si el trabajo del agente es de corta duración, quizá un servidor entero no sea la unidad adecuada. ¿VPS o sandbox? explica cuándo encaja mejor una microVM que vive un minuto. Si no, aquí están los planes, y la referencia de MCP enumera todas las herramientas con sus parámetros.