La biblioteca de comandos de Cloudways MCP: comandos básicos para servidores y aplicaciones que de verdad vas a usar

Cloudways MCP puede hacer mucho más que mostrar una lista de servidores y comprobar su estado.

Una vez conectado, puedes hacer una copia de seguridad de una aplicación, reiniciar un servicio, escalar un servidor o clonar un entorno completo, todo con solo escribir un comando. Este artículo es la guía práctica para todas esas funciones y retoma directamente donde empezó la serie.

Artículo 1 demostró el concepto con unas cuantas órdenes. Este artículo retoma el tema a partir de ahí y cubre el conjunto completo de herramientas predeterminadas: las 65 herramientas disponibles en cuanto te conectas, sin necesidad de cambiar de conjunto de herramientas.

Antes de empezar

Varias de las instrucciones que aparecen a continuación modifican algo en tu servidor o aplicación, no solo informan sobre ello. Para realizar copias de seguridad, escalar, reiniciar y eliminar, se necesita un token de acceso de Cloudways con ámbito de acceso «Limitado» o «Completo». Si tu token es de «Solo lectura», estas instrucciones fallarán, y ese es el comportamiento esperado, no un error.

Si te has conectado con un token de solo lectura del artículo 1, crea uno nuevo antes de seguir los pasos que se indican aquí.

Teniendo esto en cuenta, empieza por donde debe empezar toda sesión de resolución de problemas: fíjate en lo que tienes realmente.

Ver lo que tienes (visibilidad de servidores y aplicaciones)

Antes de cambiar nada, ten claro con qué estás trabajando.

Toda tu flota de un vistazo

««Muéstrame todos mis servidores en funcionamiento», pide el herramienta server_list . Te muestra todos los servidores de tu cuenta con su estado, proveedor de nube, región, dirección IP y cuántas aplicaciones alojan.

Para una agencia, esta única instrucción te ahorra tener que iniciar sesión en la cuenta y revisar la página de la lista de servidores de cada cliente.

La IA también se encarga del filtrado natural sin que haga falta una herramienta aparte para ello.

Prueba con ««Muéstrame solo los servidores alojados en DigitalOcean»», y así se reduce la misma resultado de la lista de servidores para que coincida. No hace falta que sepas que existe un parámetro de filtro. Solo tienes que describir lo que quieres.

Hay un detalle en la respuesta que se pasa por alto fácilmente: el número de aplicaciones por servidor. Si un servidor aloja muchas más aplicaciones que los demás, suele ser la primera señal de que está soportando más carga de la que debería, mucho antes de que te des cuenta al mirar un gráfico de uso.

Enfoque en una aplicación

Una vez que sepas qué servidor te interesa, ««Mostrar detalles del servidor [ID]»» llama a server_get. Te muestra la configuración completa de ese servidor y de todas las aplicaciones que aloja. Es la respuesta perfecta cuando un cliente te pregunta «¿qué es lo que se está ejecutando realmente en mi servidor?», ya que responde directamente a esa pregunta en lugar de obligarte a consultar dos pantallas diferentes.

Para profundizar un poco más, «mostrar detalles de mi aplicación de WordPress» llama a app_get, que devuelve la configuración de esa aplicación concreta.

Si un servidor aloja más de una aplicación y no sabes a cuál te refieres, empieza con «enumerar todas las aplicaciones del servidor [ID]», que ejecuta app_list. La mayoría de las herramientas a nivel de aplicación necesitan que se identifique una aplicación concreta, no solo que se dé por supuesto, así que vale la pena ejecutar esto primero siempre que no estés seguro.

Aquí es también donde las instrucciones vagas suelen salir mal. Si tienes tres sitios web de clientes en un mismo servidor y dices «comprueba mi app», la IA no tiene forma de saber a cuál te refieres. Nombrarla explícitamente, como «mi sitio de pruebas para el cliente X», evita por completo esa ambigüedad.

Copias de seguridad: protégete antes de tocar nada

Las siguientes secciones te guían a través de los cambios: reiniciar servicios, escalar servidores, clonar aplicaciones. Antes de nada, adquiere el hábito que debe ser lo primero: haz una copia de seguridad.

Haz una copia de seguridad antes de tocar nada

«Hacer una copia de seguridad de mi app de producción antes de publicar los cambios» llama a app_backup. Crea una copia de seguridad puntual de esa aplicación concreta.

Para cualquier cosa que vaya más allá de un simple cambio en una aplicación, «crea una copia de seguridad completa del servidor [ID]» llama a server_backup, que hace una copia de seguridad de todas las aplicaciones de ese servidor de una sola vez. Esta es la opción adecuada antes de un cambio a nivel de servidor, como un escalado o una actualización de paquetes, ya que protege todo lo que hay en el servidor, no solo un sitio.

Haz que esto sea un hábito y no algo puntual. Cada indicación en las operaciones diarias» del artículo 1 es más seguro si antes ejecutas una orden de respaldo. Solo te cuesta una frase más, y es la diferencia entre que un error sea una simple molestia o que te haga perder un cliente.

Comprobar el progreso y restaurar

Las copias de seguridad, al igual que la mayoría de las demás acciones que requieren tiempo real, se ejecutan en segundo plano. «¿Ya se ha terminado mi copia de seguridad?» llama a operation_status, y funciona para cualquier operación asíncrona, no solo para las copias de seguridad. El mismo patrón de mensaje comprueba si hay un clon, una ampliación o una restauración en curso. No necesitas un mensaje diferente para cada una.

Si algo sale mal, «restablece mi app a la última copia de seguridad» se ejecuta app_restore. Como tengo una app de WordPress en mi servidor, puedo ser más específico y pedir: «restaura mi aplicación de WordPress a la última copia de seguridad».

Y si resulta que la restauración en sí misma es un error, «deshaz esa restauración» llama a app_restore_rollback. Este es un detalle que la mayoría de los lectores no saben que existe hasta que lo necesitan en un momento de pánico, y vale la pena recordarlo ahora, antes de que llegue ese momento.

Mantener todo en marcha (control de servicios)

Revisión médica

«¿Están todos los servicios en buen estado en mi servidor de producción?» Llamadas a service_status, que te informa sobre NGINX, MySQL, PHP-FPM y cualquier otro servicio que se esté ejecutando, todo en una sola llamada.

Haz esto primero cuando notes que algo no va bien pero aún no sepas por dónde empezar a buscar, antes de recurrir a un gráfico de monitorización.

Vale la pena dejar claro en qué se diferencia esto de server_get, ya que la diferencia no resulta obvia solo por los nombres de las herramientas. server_get te dice qué está configurado. service_status te dice qué se está ejecutando en este momento y si todo va bien ahora mismo. Uno es un esquema, el otro es un control de estado.

Reiniciar sin pasar por el panel de control

«Reinicia PHP-FPM en el servidor [ID]» llama a service_state_update, que acepta «start», «stop» o «restart» como acción.

Esta misma herramienta también gestiona otros servicios. «Reiniciar MySQL en el servidor [ID]» usa la misma herramienta, solo que indica un servicio diferente. No hace falta que te aprendas un comando distinto para cada uno.

Al reiniciar un servicio en vivo, se interrumpe brevemente cualquier cosa que dependa de él. Para la mayoría de los servicios, esto supone un inconveniente menor, pero piénsatelo dos veces antes de reiniciar una base de datos de producción a mediodía, ya que la interrupción afecta a todas las aplicaciones que dependen de ella.

Capas de caché

««Borrar todas las cachés de mi blog de WordPress» llama a app_purge_cache, que borra la caché de la aplicación, Varnish y la caché de objetos de una sola vez.

Si necesitas más control sobre Varnish en concreto, «activa Varnish para esta aplicación» llama a varnish_app_manage a nivel de aplicación, mientras que el equivalente para todo el servidor es varnish_manage. Si gestionas varias aplicaciones en un mismo servidor, es importante que sepas qué nivel estás activando o desactivando, ya que la versión a nivel de aplicación solo afecta a ese sitio concreto, mientras que la versión a nivel de servidor afecta a todo lo que hay en ese servidor.

Esta es la solución directa para una situación que probablemente ya te haya pasado: un cliente te dice «no se ven mis cambios» y, nueve de cada diez veces, vaciar la caché lo soluciona.

Dimensionamiento y escalado de tus servidores

Cambiar la capacidad

»«Aumenta la memoria RAM de mi servidor a 4 GB»» llama a server_scale. El escalado provoca un breve tiempo de inactividad. Eso supone un coste real que vale la pena tener en cuenta antes de enviar la orden, sobre todo en un servidor de producción durante el horario laboral.

El almacenamiento funciona de forma diferente según el proveedor de servicios en la nube que tengas, y en este aspecto, si te equivocas, simplemente no pasa nada. ««Cambiar el tamaño del volumen de almacenamiento en el servidor [ID]» llama a server_scale_volume si tu servidor se ejecuta en AWS o GCE, o server_storage_scale si se ejecuta en DigitalOcean Block Storage. Si la solicitud de cambio de tamaño del almacenamiento no funciona, lo primero que debes comprobar es en qué proveedor está realmente tu servidor, ya que pedir la herramienta equivocada al proveedor equivocado no funcionará en absoluto.

Crear y eliminar infraestructura

«Crea un servidor de DigitalOcean de 2 GB en Nueva York llamado testServer2 con una aplicación de WordPress llamada testWPApp2» llama a server_create, que aprovisiona el servidor y preinstala la aplicación en un solo paso. Para una agencia, esto convierte un proceso de aprovisionamiento de varias pantallas en una sola frase, lo cual es lo más importante durante la incorporación de un cliente.

«Elimina el servidor antiguo que ya no uso» llama a server_delete. Esto es definitivo. Elimina el servidor y todas las aplicaciones alojadas en él, sin posibilidad de recuperarlas.

La advertencia del artículo 1 sigue siendo válida aquí, pero vale la pena convertirla en un hábito de verdad, en lugar de una advertencia que lees una vez y te olvidas. Antes de enviar un comando de eliminación, ejecuta «list server IDs», que muestra todos los ID de servidor. Siempre debes confirmar el ID del servidor antes de ejecutar cualquier otro comando, para asegurarte de que no estás eliminando o modificando un servidor que no querías. «

Clonación para ganar velocidad

«Clona el servidor [ID] para crear una versión de prueba» llama a app_clone, y clona la aplicación en el mismo servidor. ««Clonar mi app del servidor A al servidor B»» llama a app_clone_to_server , y traslada el clon a un servidor totalmente diferente.

Esta distinción tiene importancia en la práctica. La clonación en el mismo servidor es rápida y barata, y es lo que te conviene para hacer pruebas rápidas. La clonación entre servidores es la forma en que las agencias migran el sitio web de un cliente a un servidor más grande o diferente sin que el sitio deje de funcionar durante el proceso.

Si vas a duplicar un entorno completo en lugar de solo una aplicación, «clona el servidor [ID] en un nuevo servidor con las mismas aplicaciones» llama a server_clone. Esto es útil para las agencias que tienen un entorno de plantilla y quieren poner en marcha la misma configuración para un nuevo cliente sin tener que volver a crearla desde cero.

Averiguar qué pasa (supervisión y resolución de problemas)

Uso de recursos

««Mostrar el uso de la CPU de mi servidor en las últimas 24 horas para el servidor [ID]» llama a monitoring_server_graph. No se limita solo a la CPU. La misma herramienta también cubre la memoria y otras métricas, y acepta cualquier intervalo de tiempo que le indiques. ««Mostrar el uso de memoria de los últimos 7 días» funciona exactamente igual. También puedes combinar los dos parámetros en una sola orden

Para una revisión más exhaustiva, «¿cuánto ancho de banda y espacio en disco he usado» llama a monitoring_server_summary. Este es el comando al que debes recurrir cuando un cliente te pregunte por los límites de uso o cuando estés decidiendo si realmente es hora de ampliar la capacidad.

Patrones de tráfico

««Mostrar las principales direcciones IP que han visitado mi tienda en la última hora» llama a analytics_app_traffic. Esta es la respuesta directa al caso práctico de comercio electrónico del artículo 1: distinguir un pico de ventas real de un ataque de bots, usando datos reales de tráfico en lugar de hacer conjeturas.

Si quieres ver un periodo más largo, «muéstrame el tráfico de los últimos 30 días, desglosado por días» llama a analytics_app_traffic_details. Usa esta opción cuando quieras ver una tendencia a lo largo del tiempo, y usa la opción de tráfico más sencilla cuando tengas que analizar algo que está pasando ahora mismo.

Páginas y consultas lentas

«¿Qué páginas PHP son las más lentas de mi app?» llama a analytics_app_php. ««Mostrar las consultas MySQL lentas de mi app» llama a analytics_app_mysql. Ambas te llevan directamente al verdadero cuello de botella, en lugar de dejarte adivinando si el problema está en tu código o en tu base de datos.

Del mismo modo, «¿qué tal van mis tareas de cron?» llama a analytics_app_cron. Las tareas cron que fallan sin avisar, ya sea una copia de seguridad que no se ha hecho o un correo programado que no llega, son uno de los problemas ocultos más comunes en el alojamiento web, y esta pregunta te permite detectarlas sin tener que rebuscar en los registros.

Conceptos básicos de seguridad: detectar los problemas a tiempo

Análisis de vulnerabilidades

«Analiza mi sitio de WordPress en busca de vulnerabilidades» no llama solo a una herramienta. Encadena dos: app_vulnerabilities_refresh inicia un nuevo análisis, y app_vulnerabilities_list recoge los resultados una vez finalizado. Se trata del mismo comportamiento de encadenamiento que se presentó en el artículo 1, ahora con un ejemplo concreto. No hace falta que sepas que son dos llamadas distintas. Simplemente recibes los resultados.

Complementos: activar y desactivar funciones

Qué hay disponible

«¿Qué complementos tengo disponibles?» calls addon_list, que te muestra el estado y el precio de todo lo que puedes activar. Vale la pena ejecutarlo antes de recomendarle un complemento de pago a un cliente, para que puedas darle un presupuesto exacto en lugar de tener que adivinarlo.

Activar y desactivar

«Activar [complemento] en el servidor [ID]» llama a addon_activate_on_server, con ámbito limitado a ese servidor concreto.

Apagar algo requiere más cuidado. «Desactiva [complemento]» llama a addon_deactivate a nivel de cuenta, mientras que addon_deactivate_on_server limita esa misma acción a un solo servidor. Si eliges la versión para toda la cuenta cuando en realidad querías la específica del servidor, puedes afectar a servidores que no tenías intención de modificar.

Unas cuantas reglas que se aplican a todas las categorías

Las órdenes de solo lectura, es decir, cualquier cosa que muestre una lista, obtenga información, compruebe el estado o resuma, siempre son seguras y puedes explorarlas libremente. Prueba variaciones más allá de los ejemplos exactos que te he dado antes. Aquí no hay nada que se pueda estropear por hacer una pregunta.

Cualquier cosa que cambie de estado merece que le eches un segundo vistazo antes de enviarla. Esto incluye el escalado, el reinicio, la eliminación y la clonación. Dos herramientas de este artículo son, con diferencia, las que tienen más en juego: server_delete y app_delete. Ambas son permanentes y ninguna incluye un paso de confirmación aparte del que tú mismo das.

La precisión siempre gana a la brevedad. Compara ««comprueba mi servidor»» con «muéstrame la CPU y la memoria del servidor 12345 en los últimos 7 días». La segunda te da una respuesta precisa y útil a la primera. La primera hace que la IA tenga que adivinar a qué servidor, qué métrica y qué intervalo de tiempo te referías realmente.

Cómo convertir la gestión de la flota de servidores en una conversación natural

El MCP de Cloudways transforma de raíz la forma en que los desarrolladores y las agencias gestionan la infraestructura de alojamiento. Al permitir el acceso directo a 65 herramientas clave mediante el lenguaje natural, el MCP elimina las dificultades que supone navegar por paneles de control de varios pasos, cotejar pantallas de servidor y memorizar la sintaxis de la CLI.

Tanto si estás haciendo comprobaciones de salud rutinarias, como si estás ampliando los recursos ante picos de tráfico o identificando cuellos de botella en el rendimiento de consultas lentas a la base de datos, el flujo de trabajo se reduce a un único principio: sé específico, protege los cambios en el estado del servidor o la aplicación con copias de seguridad, y describe lo que necesitas. A medida que integres estas indicaciones en tus operaciones diarias, Cloudways MCP convierte la compleja gestión de servidores en un proceso fluido y coloquial, lo que te ahorra tiempo, reduce los errores humanos y te permite centrarte en lo que realmente importa: crear y escalar tus aplicaciones.

Y aquí sigue válendo lo mismo que en el artículo 1: si quieres algo que todavía no aparece en ninguna lista, pregúntalo directamente. La pregunta «¿Qué puedes hacer con mi cuenta de Cloudways?» lo muestra a través del mismo mecanismo de descubrimiento de conjuntos de herramientas que hace funcionar todo en las operaciones del MCP de Cloudways.