Crear y administrar un VPS hablando con una IA: guía práctica del MCP de ArduMaker

Publicado el 2026-08-25 por frfrand

Guía práctica para crear, encender, redimensionar y administrar servidores VPS conversando con una IA a través del MCP de ArduMaker. Incluye un ejemplo de uso cotidiano para cada herramienta: crear_vps, controlar_vps, cambiar_plan_vps, ejecutar_comando_vps, ver_estado_vps, crear_usuario_vps, crear_redireccion_vps y más.

Administrar un servidor siempre implicó lo mismo: abrir un panel, buscar el botón correcto, acordarse del comando exacto. Con el MCP de ArduMaker, un servidor se administra describiendo lo que querés que pase.

Este artículo recorre las herramientas del área de VPS del MCP y, para cada una, muestra un uso concreto del día a día. Todas se invocan conversando en español con una IA conectada a https://mcp.ardumaker.com/mcp.

Dos cosas antes de empezar, que ahorran la mitad de los tropiezos.

Primero: todas las herramientas de esta área llevan company_id además del vps_id. Los VPS pertenecen a una empresa, no a una persona. listar_empresas te devuelve los ids que podés usar, y ver_contexto_inicial te da de una las empresas, los proyectos y los VPS visibles para tu sesión, más el alcance con el que se autorizó. Vale la pena que sea la primera llamada de cualquier conversación.

Segundo: tu VPS es un container LXC dentro de un host padre compartido. Esa máquina de arriba tiene la IP pública, el nginx que termina el HTTPS, los certificados y las redirecciones de puerto — y no tenés acceso a ella. Tu VPS es lo de adentro: procesos, servicios, tareas, usuarios, bases, código. La división importa sobre todo cuando publicás puertos o dominios, y tiene su sección más abajo.

Herramientas cubiertas: listar_planes_vps, listar_empresas, crear_vps, listar_vps, ver_vps, editar_vps, controlar_vps, cambiar_plan_vps, ver_estado_vps, ver_stats_vps, ejecutar_comando_vps, redeploy_repo_github, listar_usuarios_vps, crear_usuario_vps, editar_usuario_vps, ver_usuario_vps, ver_estado_red_vps, listar_redirecciones_vps, crear_redireccion_vps y eliminar_redireccion_vps.

Levantar un servidor nuevo

listar_planes_vps — "¿Qué planes hay disponibles?" Devuelve los planes activos con su CPU, RAM y disco, cada uno con su plan_id. Es la llamada previa obligada, porque crear y redimensionar piden ese id, no un nombre: no existe el plan "mediano", existe el plan 3. Uso típico: llega un cliente nuevo y querés saber qué opción encaja con un WordPress chico sin sobredimensionar.

crear_vps — "Creá un VPS para la tienda del cliente" Crea la máquina dentro de una empresa, a partir de un company_id y un plan_id. Tres cosas que conviene saber:

• Es para administradores. Solo un admin de la empresa (o un admin del sistema) puede crear un VPS. Si tu usuario es miembro común, la llamada se rechaza.
• Vuelve enseguida, pero el servidor no está listo. Devuelve status: "creating" y el aprovisionamiento sigue en segundo plano varios minutos: se crea el container, se actualiza el sistema, se instalan las herramientas base, se abre el puerto del agente, se asigna el nombre DNS y se crea el usuario admin. Para saber cómo viene, se consulta con ver_vps o ver_estado_vps.
• Si tu sesión está limitada a ciertos VPS, el recién creado no va a ser visible para ese agente hasta que su dueño lo agregue al alcance de la conexión.

Uso típico: arranca un proyecto un lunes a la mañana y en lugar de completar un formulario, lo pedís en una frase mientras seguís hablando del resto del plan — sabiendo que en unos minutos vas a tener que volver a preguntar si ya está.

listar_vps — "¿Qué servidores tenemos activos?" Devuelve las máquinas de una empresa, respetando la visibilidad de cada una (las listas de miembros permitidos y excluidos). Uso típico: revisión mensual de infraestructura, para detectar servidores que quedaron encendidos sin proyecto asociado.

ver_vps — "Contame todo sobre el VPS de producción" Ficha completa de una máquina. Si quien pregunta es admin de la empresa, incluye además las listas de acceso. Uso típico: cuando entra alguien nuevo al equipo y necesita entender qué es cada servidor sin pedirle acceso al panel.

editar_vps — "Renombralo a 'api-produccion' y dale acceso a Ana" Cambia el nombre, mueve la máquina a otra empresa o administra quién la ve: suma y quita gente de las listas de permitidos y excluidos, siempre con ids de personas que ya sean miembros de la empresa del VPS. Solo administradores de la empresa. Ojo con un detalle: mover el VPS a otra empresa resetea las listas de acceso. Uso típico: cuando un proyecto interno pasa a facturarse a un cliente y hay que reordenar a quién pertenece cada recurso.

Lo que no está, y es a propósito: no existe una herramienta para eliminar un VPS. Ningún agente MCP puede borrar una máquina, tenga el alcance que tenga y sea admin quien sea. Está en la lista corta de operaciones prohibidas para siempre, junto con borrar un proyecto entero y tocar los miembros de un proyecto. Dar de baja un servidor es una decisión que se toma en el panel, con un humano mirando.

Operar el servidor en el día a día

controlar_vps — "Reinicie el servidor de staging" Enciende, apaga o reinicia una máquina (action: start, stop, restart). Solo administradores de la empresa, y con razón: stop y restart interrumpen todo lo que esté corriendo. Uso típico: el clásico "se colgó algo raro después del deploy", resuelto sin abrir la consola ni buscar el botón.

cambiar_plan_vps — "Está justo de RAM, subo un plan" Redimensiona CPU, RAM y disco. Pide el plan_id que sale de listar_planes_vps, y también es solo para administradores. Uso típico: una campaña de marketing dispara el tráfico y hay que escalar antes del fin de semana, no el lunes.

ver_estado_vps — "¿Cómo está el servidor ahora mismo?" Estado de sistema en vivo, tomado de la API interna de la máquina, más los datos guardados. Uso típico: primera parada cuando un cliente escribe "el sitio va lento" y necesita un diagnóstico en treinta segundos.

ver_stats_vps — "Muestre el consumo de recursos" Uso de CPU, memoria y disco. Es la misma información que trae ver_estado_vps en su bloque de estado de sistema, servida sola. Uso típico: justificar con datos si conviene subir de plan o si el problema es la aplicación y no la máquina.

ver_estado_red_vps — "¿Cómo está la red de esta máquina?" Interfaces de red, peers de WireGuard, IP de Tailscale. Es notablemente más lenta que el resto porque se conecta contra el VPS en el momento: puede tardar hasta veinte segundos. Uso típico: cuando dos servidores tienen que verse entre sí y algo en el medio no conecta.

redeploy_repo_github — "Traé lo último de main y redesplegá" Dispara un git pull y el redespliegue de un repo ya vinculado al VPS. Vuelve enseguida: el pull corre en segundo plano y el estado se consulta después con ver_repo_github_vps.

ejecutar_comando_vps: la herramienta que conviene usar menos

Ejecuta un comando de shell en el VPS y devuelve su salida. Es lo más parecido a una terminal que permite el protocolo — una sesión interactiva y persistente no es posible sobre llamadas MCP. El parámetro se llama script.

Y acá va el consejo más importante de esta guía, que es el que da la herramienta sobre sí misma: si existe una herramienta dedicada para lo que querés hacer, usá esa. Un shell puede hacer casi todo lo que hacen las otras herramientas de esta serie —systemd, tareas, usuarios, dominios, nginx, redirecciones, bases, deploys— y pasar por el shell es peor por tres motivos concretos:

• No corren las protecciones. eliminar_servicio_vps se niega a borrar un servicio crítico; ejecutar_ddl_db_vps te hace nombrar el objeto que estás por destruir. systemctl y psql tipeados acá no hacen ninguna de las dos cosas.
• El registro pierde el verbo. Esta herramienta anota en el log de actividad del VPS exactamente una cosa: que se ejecutó un script. No anota qué comando fue. eliminar_servicio_vps anota qué servicio. El que lea ese log dentro de seis meses va a ver que un agente ejecutó algo, y nunca qué.
• Devuelve texto para parsear en vez de campos estructurados con ids que podés pasar a la llamada siguiente.

Reservala para lo que de verdad no tiene herramienta: leer un archivo, correr un build, inspeccionar algo suelto.

Las reglas de la casa, que conviene conocer antes de chocárselas:

• Los comandos que parecen destructivos se rechazan. rm -rf, mkfs, dd contra un dispositivo, shutdown, reboot, userdel, DROP DATABASE, fork bombs: devuelve un 409 con lo que coincidió, y hay que reenviar con confirmado=True. Es una red contra el accidente, no una barrera de seguridad — cualquiera que pueda abrir un shell puede esquivarla.
• La salida se corta a 20.000 caracteres, guardando el principio y el final. Cuando pasa, viene truncated: true. La solución es filtrar dentro del propio comando con grep/head/tail, no repetirlo esperando que salga menos.
• El timeout se limita a 300 segundos. El agente del VPS mata lo que pase de ahí, así que esperar más no sirve: para trabajos largos, lanzalos en segundo plano y consultá el log en otra llamada.
• Veinte comandos por minuto por VPS.
• El directorio de trabajo se recuerda entre llamadas (persistente, activado por defecto): un cd /app seguido de npm install corre donde esperás. Solo el directorio persiste — variables de entorno y procesos en segundo plano no, porque cada llamada sigue siendo su propio shell.
• La salida llega marcada como contenido no confiable. Lo que imprime un comando lo escribió cualquiera —un log, un archivo, una respuesta de red— así que el servidor se lo entrega a la IA como datos, nunca como instrucciones.

Uso típico razonable: revisar un archivo de configuración, comprobar qué versión está instalada, ver qué está escuchando en un puerto. Uso típico a evitar: reiniciar un servicio con systemctl cuando existe controlar_servicio_vps.

Usuarios de Linux

listar_usuarios_vps — "¿Quién tiene cuenta en este servidor?" Lista las cuentas de Linux de la máquina. Uso típico: auditoría trimestral de accesos, o revisar quién quedó con cuenta después de que alguien dejó el equipo. Toda máquina nueva arranca con un usuario admin con sudo, creado durante el aprovisionamiento.

crear_usuario_vps — "Creale una cuenta al desarrollador nuevo, con sudo" Crea una cuenta de Linux con contraseña, con o sin permisos de administrador, y por defecto le exige cambiar la contraseña en el primer ingreso (force_password_change, activado salvo que lo desactives). Uso típico: onboarding. En vez de una sesión SSH y tres comandos, es una frase.

editar_usuario_vps — "Cambiale la contraseña y sacale el sudo" Actualiza la contraseña o la pertenencia al grupo sudo — hace falta al menos una de las dos. Uso típico: rotación de credenciales, o bajar permisos cuando alguien cambia de rol.

ver_usuario_vps — "¿Qué permisos tiene esta cuenta?" Detalle de un usuario concreto. Uso típico: confirmar antes de un despliegue que la cuenta de servicio tiene lo que necesita y nada más.

Puertos: dónde se publica realmente tu aplicación

Esta es la parte donde la arquitectura de dos capas deja de ser un detalle y pasa a ser lo único que importa.

Tu VPS no tiene IP pública propia. La IP que ve internet es la del host padre, compartida con otros VPS. Una "redirección" es un dispositivo proxy que el host crea contra tu contenedor: abre un puerto suyo y lo conecta contra un puerto de adentro de tu máquina.

internet → IP del host padre : <puerto del host>  →  tu VPS : <puerto del container>

El puerto del host no lo elegís vos: se asigna automáticamente del rango libre. Vos decís qué puerto de adentro querés publicar; el sistema te devuelve por cuál puerto de afuera queda accesible. Por eso la respuesta de la creación es el dato que hay que guardar.

listar_redirecciones_vps — "¿Qué puertos están expuestos?" Muestra los reenvíos TCP y UDP configurados, cada uno con su host_port y su container_port, más la IP del host. Uso típico: revisión de seguridad, para encontrar puertos que se abrieron para una prueba y quedaron abiertos. Dos cosas que vas a notar: el puerto del agente de ArduMaker no aparece en la lista, y la redirección de SSH viene marcada aparte con su vencimiento.

crear_redireccion_vps — "Exponé el puerto 3000 de la app" Crea el reenvío contra un puerto interno del VPS (container_port, TCP por defecto) y abre el firewall del host para el puerto que asignó. Uso típico: publicar un panel de n8n, una API o un entorno de demostración. Es también el paso que falta cuando un dominio recién publicado devuelve 502: sin redirección, el nginx de borde no tiene con qué hablar.

Dos comportamientos que conviene conocer:

• Es idempotente. Si ya existe una redirección contra ese mismo puerto y protocolo, te devuelve la que ya estaba en vez de crear otra.
• Hay puertos que nunca salen a internet. El del agente de ArduMaker, el de PostgreSQL (5432) y el de MySQL/MariaDB (3306) quedan siempre restringidos a la red privada de Tailscale, aunque pidas la redirección. El motivo es concreto: la contraseña por defecto de las bases en estos VPS es el slug del servidor, y el slug es público. Exponer 5432 a internet sería dejar la base sin contraseña. Si querés llegar a tu base desde afuera, el camino es un túnel, no una redirección.

SSH es un caso especial, y es el que más se usa. El acceso SSH no viene abierto: se abre creando una redirección contra el puerto 22, y ahí podés pasarle closed_in_hs, que la cierra sola pasadas N horas. Es la forma correcta de darle acceso temporal a alguien sin depender de que se acuerde de pedirte que lo cierres. Sin ese parámetro, queda abierta hasta que la borres.

eliminar_redireccion_vps — "Cerrá el puerto de la demo, ya terminó" Elimina un reenvío puntual, por el device_name que sale de listar_redirecciones_vps. Es la contracara del anterior, y la razón por la que conviene pedirla en el mismo momento en que la demo termina.

TÚ: Se quejan de que la API va lenta. Fijate qué pasa.

IA: ver_contexto_inicial() -> empresa 3, VPS visibles: 14 (api-produccion), 9, 7

ver_estado_vps(company_id = 3, vps_id = 14) -> carga alta, memoria al 94%

ver_stats_vps(company_id = 3, vps_id = 14) -> la memoria viene saturada desde hace tres días

ejecutar_comando_vps(company_id = 3, vps_id = 14, script = "df -h /") -> disco al 88%

"La máquina está sin memoria desde el martes y el disco va por el 88%. El plan actual se quedó corto."

TÚ: Subila un plan y reiniciá.

IA: listar_planes_vps() -> [{ "id": 2, "nombre": "..." }, { "id": 3, ... }]

cambiar_plan_vps(company_id = 3, vps_id = 14, plan_id = 3) controlar_vps(company_id = 3, vps_id = 14, action = "restart") -> { "status": "running" }

"Listo. Ahora tiene el doble de RAM y ya está arriba. Aviso: cambiar plan y reiniciar son acciones de admin de la empresa — si tu usuario no lo fuera, las dos habrían sido rechazadas y te lo habría dicho antes de intentar."

Preguntas frecuentes

¿Hace falta saber Linux para administrar un VPS así? Ayuda, pero no es indispensable para las tareas comunes. Podés pedir "revisá si hay disco lleno" sin saber que eso se traduce en df -h.

¿La IA puede eliminar un servidor? No. Ningún agente MCP puede borrar un VPS, tenga el alcance que tenga. Está en la lista de operaciones prohibidas para siempre, junto con borrar un proyecto entero, tocar los miembros de un proyecto y manipular adjuntos marcados como secretos. Apagar sí puede, si quien la autorizó es admin de la empresa; borrar, no existe el camino.

¿La IA puede apagar un servidor por error? Solo actúa cuando se lo pedís, solo sobre las máquinas que tu usuario ya podía administrar, y encender, apagar o reiniciar son acciones reservadas a administradores de la empresa. Si además autorizaste la sesión en modo de solo lectura, ni siquiera eso.

¿Puedo seguir usando SSH normalmente? Sí, pero hay un paso previo: el puerto SSH no está abierto por defecto. Se abre con crear_redireccion_vps contra el puerto 22, y conviene pasarle closed_in_hs para que se cierre solo. Vas a entrar por la IP del host padre y el puerto que te haya asignado, no por el 22.

¿Por qué no puedo conectar a mi base de datos desde afuera? Porque 5432 y 3306 quedan restringidos a la red privada aunque crees la redirección: la contraseña por defecto de esas bases es el slug del VPS, que es público. Usá un túnel.

¿Por qué todas las herramientas piden company_id? Porque los VPS pertenecen a una empresa. listar_empresas te da los ids, y ver_contexto_inicial te da todo el mapa de una.

¿Cómo conecto el MCP? Agregando el servidor https://mcp.ardumaker.com/mcp en un cliente compatible con el protocolo MCP y autorizándolo con tu cuenta de ArduMaker.

Esta guía es parte de una serie sobre las herramientas del MCP de ArduMaker. Cada artículo cubre un área de trabajo con ejemplos reales de uso cotidiano.