Create and manage a VPS by talking to an AI: practical guide to ArduMaker's MCP

Published on 2026-08-25 by 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.

Managing a server has always meant the same thing: open a panel, look for the right button, remember the exact command. With ArduMaker's MCP, a server is managed by describing what you want to happen.

This article walks through the tools in the VPS area of the MCP and, for each one, shows a concrete day-to-day use case. All are invoked by conversing in Spanish with an AI connected to https://mcp.ardumaker.com/mcp.

Two things before starting, which save half the stumbling blocks.

First: all tools in this area carry company_id in addition to vps_id. VPSs belong to a company, not a person. listar_empresas returns the IDs you can use, and ver_contexto_inicial gives you at once the companies, projects, and VPSs visible for your session, plus the scope with which you were authorized. It's worth making it the first call of any conversation.

Second: your VPS is an LXC container inside a shared parent host. That machine above has the public IP, the nginx that terminates HTTPS, the certificates, and the port redirects — and you don't have access to it. Your VPS is what's inside: processes, services, tasks, users, databases, code. The division matters especially when publishing ports or domains, and it has its own section below.

Tools covered: 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.

Setting up a new server

listar_planes_vps — "What plans are available?" Returns active plans with their CPU, RAM, and disk, each with its plan_id. It is the mandatory preliminary call, because creating and resizing require that id, not a name: there is no "medium" plan, there is plan 3. Typical use: a new client arrives and you want to know which option fits a small WordPress without overprovisioning.

crear_vps — "Create a VPS for the client's store" Creates the machine within a company, based on a company_id and a plan_id. Three things worth knowing:

• It is for administrators. Only a company admin (or a system admin) can create a VPS. If your user is a regular member, the call is rejected.
• It returns right away, but the server is not ready. It returns status: "creating" and provisioning continues in the background for several minutes: the container is created, the system is updated, base tools are installed, the agent port is opened, the DNS name is assigned, and the admin user is created. To see how it is coming along, query with ver_vps or ver_estado_vps.
• If your session is limited to certain VPS, the newly created one will not be visible to that agent until its owner adds it to the connection scope.

Typical use: you start a project on a Monday morning and instead of filling out a form, you ask for it in one sentence while continuing to talk about the rest of the plan — knowing that in a few minutes you'll have to ask again if it's ready.

listar_vps — "What active servers do we have?" Returns a company's machines, respecting the visibility of each one (allowed and excluded member lists). Typical use: monthly infrastructure review, to detect servers left running without an associated project.

ver_vps — "Tell me everything about the production VPS" Full details of a machine. If the person asking is a company admin, it also includes the access lists. Typical use: when someone new joins the team and needs to understand what each server is without asking for access to the panel.

editar_vps — "Rename it to 'api-produccion' and give Ana access" Changes the name, moves the machine to another company, or manages who sees it: adds and removes people from the allowed and excluded lists, always with IDs of people who are already members of the VPS's company. Company administrators only. Watch out for one detail: moving the VPS to another company resets the access lists. Typical use: when an internal project starts being billed to a client and you need to reorganize who owns each resource.

What is not there, and it is on purpose: there is no tool to delete a VPS. No MCP agent can delete a machine, regardless of its scope or who the admin is. It is on the short list of operations that are permanently prohibited, along with deleting an entire project and touching project members. Decommissioning a server is a decision made in the panel, with a human watching.

Operate the server on a day-to-day basis

controlar_vps — "Restart the staging server" Turns on, shuts down, or restarts a machine (action: start, stop, restart). Company administrators only, and for good reason: stop and restart interrupt everything that is running. Typical use: the classic "something weird froze after the deploy", resolved without opening the console or looking for the button.

cambiar_plan_vps — "It's just short on RAM, I'll upgrade the plan" Resizes CPU, RAM, and disk. Requires the plan_id from listar_planes_vps, and is also for administrators only. Typical use: a marketing campaign spikes traffic and you need to scale before the weekend, not on Monday.

ver_estado_vps — "How is the server right now?" Live system status, taken from the machine's internal API, plus saved data. Typical use: first stop when a client writes "the site is slow" and you need a diagnosis in thirty seconds.

ver_stats_vps — "Show me resource consumption" CPU, memory, and disk usage. It's the same information that ver_estado_vps brings in its system status block, served alone. Typical use: justify with data whether it's worth upgrading the plan or if the problem is the application and not the machine.

ver_estado_red_vps — "How is the network of this machine?" Network interfaces, WireGuard peers, Tailscale IP. It is notably slower than the rest because it connects to the VPS at the moment: it can take up to twenty seconds. Typical use: when two servers need to see each other and something in between is not connecting.

redeploy_repo_github — "Pull the latest from main and redeploy" Triggers a git pull and redeployment of a repo already linked to the VPS. It returns immediately: the pull runs in the background and the status is queried later with ver_repo_github_vps.

ejecutar_comando_vps: the tool you should use less

Executes a shell command on the VPS and returns its output. It is the closest thing to a terminal allowed by the protocol — an interactive and persistent session is not possible over MCP calls. The parameter is called script.

And here goes the most important advice of this guide, which is the one the tool gives about itself: if there is a dedicated tool for what you want to do, use that. A shell can do almost everything the other tools in this series do —systemd, tasks, users, domains, nginx, redirects, databases, deploys— and going through the shell is worse for three concrete reasons:

• Protections do not run. eliminar_servicio_vps refuses to delete a critical service; ejecutar_ddl_db_vps makes you name the object you are about to destroy. systemctl and psql typed here do neither of those two things.
• The log loses the verb. This tool notes in the VPS activity log exactly one thing: that a script was executed. It does not note what command was. eliminar_servicio_vps notes which service. Whoever reads that log in six months will see that an agent executed something, and never what.
• Returns text to parse instead of structured fields with ids that you can pass to the next call.

Reserve it for what truly has no tool: reading a file, running a build, inspecting something loose.

The house rules, which are good to know before running into them:

• Commands that appear destructive are rejected. rm -rf, mkfs, dd against a device, shutdown, reboot, userdel, DROP DATABASE, fork bombs: returns a 409 with what matched, and must be resent with confirmado=True. It's a net against accidents, not a security barrier — anyone who can open a shell can bypass it.
• Output is truncated to 20,000 characters, keeping the beginning and the end. When this happens, truncated: true is included. The solution is to filter within the command itself using grep/head/tail, not to repeat it expecting less output.
• Timeout is limited to 300 seconds. The VPS agent kills anything that exceeds that, so waiting longer doesn't help: for long jobs, run them in the background and check the log in another call.
• Twenty commands per minute per VPS.
• The working directory is remembered between calls (persistente, enabled by default): a cd /app followed by npm install runs where you expect. Only the directory persists — environment variables and background processes do not, because each call is still its own shell.
• Output arrives marked as untrusted content. What a command prints was written by anyone — a log, a file, a network response — so the server delivers it to the AI as data, never as instructions.

Reasonable typical use: checking a configuration file, verifying what version is installed, seeing what is listening on a port. Typical use to avoid: restarting a service with systemctl when controlar_servicio_vps exists.

Linux users

listar_usuarios_vps — "Who has an account on this server?" Lists the Linux accounts on the machine. Typical use: quarterly access audit, or checking who still has an account after someone left the team. Every new machine starts with an admin user with sudo, created during provisioning.

crear_usuario_vps — "Create an account for the new developer, with sudo" Creates a Linux account with a password, with or without administrator permissions, and by default requires changing the password on first login (force_password_change, enabled unless you disable it). Typical use: onboarding. Instead of an SSH session and three commands, it's a phrase.

editar_usuario_vps — "Change their password and remove sudo" Updates the password or sudo group membership — at least one of the two is required. Typical use: credential rotation, or reducing permissions when someone changes roles.

ver_usuario_vps — "What permissions does this account have?" Details of a specific user. Typical use: confirming before a deployment that the service account has what it needs and nothing more.

Ports: where your application is actually published

This is the part where the two-layer architecture stops being a detail and becomes the only thing that matters.

Your VPS does not have its own public IP. The IP that the internet sees is that of the parent host, shared with other VPSs. A "redirection" is a proxy device that the host creates against your container: it opens a port of its own and connects it to a port inside your machine.

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

You do not choose the host port: it is assigned automatically from the free range. You specify which internal port you want to publish; the system returns which external port it is accessible through. That is why the creation response is the data you need to save.

listar_redirecciones_vps — "Which ports are exposed?" Shows the configured TCP and UDP forwards, each with its host_port and its container_port, plus the host IP. Typical use: security review, to find ports that were opened for a test and remained open. Two things you will notice: the ArduMaker agent port does not appear in the list, and the SSH redirection is marked separately with its expiration.

crear_redireccion_vps — "Expose port 3000 of the app" Creates the forwarding against an internal port of the VPS (container_port, TCP by default) and opens the host firewall for the port it assigned. Typical use: publishing an n8n panel, an API, or a demonstration environment. It is also the missing step when a newly published domain returns 502: without redirection, the edge nginx has nothing to talk to.

Two behaviors worth knowing:

• It is idempotent. If a redirection already exists for that same port and protocol, it returns the one that was already there instead of creating another.
• Some ports never go out to the internet. The ArduMaker agent port, the PostgreSQL port (5432) and the MySQL/MariaDB port (3306) always remain restricted to the Tailscale private network, even if you request the redirection. The reason is specific: the default password for the databases on these VPS is the server slug, and the slug is public. Exposing 5432 to the internet would be leaving the database without a password. If you want to access your database from outside, the way is a tunnel, not a redirection.

SSH is a special case, and it is the most used one. SSH access does not come open: it is opened by creating a redirection against port 22, and there you can pass closed_in_hs, which closes it automatically after N hours. It is the correct way to give temporary access to someone without relying on them remembering to ask you to close it. Without that parameter, it remains open until you delete it.

eliminar_redireccion_vps — "Close the demo port, it's over" Deletes a specific forwarding, by the device_name that comes from listar_redirecciones_vps. It is the counterpart of the previous one, and the reason why it is convenient to request it at the same time the demo ends.

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."

Frequently Asked Questions

Do you need to know Linux to manage a VPS like this? It helps, but it's not essential for common tasks. You can ask "check if the disk is full" without knowing that translates to df -h.

Can the AI delete a server? No. No MCP agent can delete a VPS, regardless of its scope. It is on the list of permanently prohibited operations, along with deleting an entire project, touching project members, and manipulating attachments marked as secret. Shutting down is possible, if the person who authorized it is a company admin; deleting, there is no way.

Can the AI shut down a server by mistake? It only acts when you ask it to, only on machines your user could already manage, and turning on, shutting down, or restarting are actions reserved for company administrators. Furthermore, if you authorized the session in read-only mode, not even that.

Can I still use SSH normally? Yes, but there's a prior step: the SSH port is not open by default. It is opened with crear_redireccion_vps against port 22, and it's advisable to pass closed_in_hs so it closes automatically. You will connect via the parent host's IP and the port assigned to you, not via port 22.

Why can't I connect to my database from outside? Because ports 5432 and 3306 are restricted to the private network even if you create the redirection: the default password for those databases is the VPS slug, which is public. Use a tunnel.

Why do all tools ask for company_id? Because VPSs belong to a company. listar_empresas gives you the IDs, and ver_contexto_inicial gives you the full map of one.

How do I connect the MCP? By adding the server https://mcp.ardumaker.com/mcp in an MCP protocol-compatible client and authorizing it with your ArduMaker account.

This guide is part of a series on ArduMaker's MCP tools. Each article covers a work area with real examples of everyday use.