Nutanix ha dado un paso relevante en la automatización de infraestructura con el lanzamiento de un servidor MCP (Model Context Protocol) para Nutanix Cloud Platform, una pieza open source que permite a asistentes y agentes de inteligencia artificial interactuar con entornos híbridos a través de la API Prism v4. La propuesta busca que herramientas como GitHub Copilot, Claude Code o Cursor puedan consultar, diagnosticar y automatizar tareas sobre la infraestructura sin saltarse los controles de acceso y gobierno ya definidos en la plataforma.

Las claves del MCP de Nutanix en 20 segundos

• Nutanix ha publicado un servidor MCP open source para Nutanix Cloud Platform.
• Los agentes acceden a la infraestructura mediante las APIs Prism v4.
• El sistema hereda controles de acceso basados en roles, auditoría y límites de uso.
• Puede utilizarse con herramientas como GitHub Copilot, Claude Code o Cursor.
• Nutanix mantiene supervisión humana y gestión asíncrona para operaciones de larga duración.

El movimiento es especialmente interesante porque traslada el concepto de IA agéntica desde la generación de código hacia un terreno mucho más delicado: la administración real de infraestructura.

Hasta ahora, pedir a una IA que explicase cómo crear una máquina virtual era relativamente sencillo. Otra cosa muy distinta es permitir que esa IA pueda consultar el estado de un clúster, identificar un problema, preparar una operación de mantenimiento o lanzar una acción contra producción.

Ahí es donde entra MCP.

Qué aporta MCP a la administración de Nutanix

Model Context Protocol se ha convertido en una forma estandarizada de conectar modelos y agentes con herramientas, datos y servicios externos.

En este caso, el servidor MCP actúa como intermediario entre el agente y Nutanix Cloud Platform.

El flujo puede simplificarse así:

Administrador
     │
     ▼
Agente de IA
     │
     ▼
Servidor MCP de Nutanix
     │
     ▼
Prism v4 API Gateway
     │
     ▼
Nutanix Cloud Platform

Una petición expresada en lenguaje natural podría convertirse en una o varias llamadas a las APIs de Nutanix.

Por ejemplo, un administrador podría pedir:

Muéstrame las máquinas virtuales con más consumo de memoria
en el clúster de producción durante las últimas horas.

El agente podría interpretar la intención, utilizar las herramientas expuestas por MCP y consultar la plataforma.

La diferencia fundamental frente a permitir que un LLM construya llamadas REST libremente es que el agente no obtiene automáticamente acceso ilimitado a la infraestructura.

El servidor trabaja sobre las APIs y permisos existentes de Nutanix.

Prism v4 se convierte en la capa de control

El elemento realmente importante del anuncio no es el lenguaje natural, sino lo que existe por debajo.

Nutanix está apoyando el servidor MCP sobre su Prism v4 API Gateway. La compañía ya considera las APIs v4 su versión recomendada para producción y está preparando la retirada progresiva de las APIs heredadas v0.8, v1, v2 y v3 a partir de una actualización prevista para el cuarto trimestre de 2026.

Las APIs v4 cubren actualmente múltiples dominios de administración, entre ellos:

• máquinas virtuales;
• almacenamiento;
• redes;
• seguridad;
• monitorización;
• gestión del ciclo de vida;
• AIOps;
• operaciones sobre Prism;
• administración multidominio;
• licencias;
• recuperación ante desastres.

Esto significa que MCP no crea una vía administrativa paralela. La intención de Nutanix es que la IA utilice las mismas interfaces sobre las que ya se aplican controles de seguridad y gobierno.

Para una empresa esta distinción es importante.

No es lo mismo conectar un chatbot directamente a credenciales de administrador que permitir a un agente trabajar mediante una API que conoce qué operaciones puede realizar cada identidad.

Los agentes también tienen RBAC

Uno de los principales problemas de los agentes de infraestructura es el alcance de sus permisos.

Nutanix plantea utilizar RBAC (Role-Based Access Control) para restringir qué APIs puede utilizar cada agente.

Un agente destinado a observabilidad podría disponer únicamente de permisos de lectura:

Agent: Infrastructure Observer

✓ listar máquinas virtuales
✓ consultar alarmas
✓ leer métricas
✓ revisar tareas

✗ crear máquinas virtuales
✗ eliminar volúmenes
✗ cambiar redes
✗ actualizar el clúster

Otro agente especializado en aprovisionamiento podría tener permisos adicionales, pero únicamente sobre determinados recursos.

Este modelo es mucho más razonable que entregar a un asistente una cuenta administrativa general.

La propia documentación de las APIs v4 muestra que las operaciones ya incorporan permisos específicos según el recurso. Por ejemplo, distintas operaciones de Prism distinguen entre roles como Cluster Admin, Prism Admin, Prism Viewer o Domain Manager Admin.

El servidor MCP aprovecha esa estructura en vez de sustituirla.

Auditoría: saber qué agente hizo qué

La siguiente dificultad aparece después de ejecutar una acción.

Si una persona elimina una máquina virtual, los sistemas empresariales necesitan registrar quién realizó la operación.

Con agentes ocurre lo mismo, pero aparece una capa adicional:

usuario
   ↓
agente
   ↓
herramienta MCP
   ↓
API
   ↓
infraestructura

Nutanix afirma que su arquitectura mantiene registros que permiten conocer qué agente inició una determinada operación.

Esto puede resultar especialmente importante cuando varias automatizaciones trabajan simultáneamente sobre la plataforma.

En un escenario empresarial no basta con que la IA responda:

“La operación se ha completado”.

Los equipos necesitan poder reconstruir posteriormente:

Quién solicitó la acción
Qué agente la interpretó
Qué herramienta utilizó
Qué API fue invocada
Qué recurso resultó afectado
Cuándo se ejecutó
Cuál fue el resultado

Esa trazabilidad será una de las condiciones necesarias para que los agentes pasen de realizar consultas a intervenir realmente en infraestructura de producción.

Nutanix añade límites para evitar que un agente se descontrole

Otro riesgo específico de la automatización basada en agentes es la velocidad.

Una persona puede cometer un error y lanzar una llamada incorrecta.

Un agente puede repetirla cientos de veces.

Nutanix incorpora mecanismos de throttling y metering sobre las APIs para controlar el volumen de llamadas.

La compañía menciona específicamente la protección frente a posibles escenarios de agent swarm, donde múltiples agentes podrían generar grandes cantidades de solicitudes simultáneamente.

Conceptualmente:

10 agentes
   │
   │ 10.000 peticiones
   ▼
API Gateway
   │
   ├── autenticación
   ├── RBAC
   ├── rate limiting
   ├── metering
   └── auditoría
   │
   ▼
Infraestructura

Para administradores acostumbrados a APIs tradicionales, esto puede parecer una medida evidente.

Con agentes autónomos será todavía más importante.

Human-in-the-loop antes de tocar producción

Nutanix tampoco plantea necesariamente una infraestructura administrada de forma completamente autónoma.

La plataforma mantiene un enfoque de human-in-the-loop, donde determinadas acciones pueden requerir supervisión o aprobación.

Esto abre la puerta a workflows como:

Administrador:
"Analiza por qué el clúster está degradado"

             ↓

Agente:
"Dos hosts necesitan actualizar firmware"

             ↓

Agente:
"Propongo ejecutar LCM esta noche"

             ↓

       APROBACIÓN HUMANA

             ↓

Prism API:
ejecutar actualización

Este modelo resulta especialmente lógico en tareas como:

• actualizaciones;
• cambios de red;
• migraciones;
• borrado de recursos;
• modificaciones de seguridad;
• operaciones de recuperación.

La IA puede realizar diagnóstico y preparar el plan, mientras que el administrador mantiene el control sobre la ejecución.

Las operaciones largas se gestionan como tareas asíncronas

La infraestructura tampoco funciona siempre como una API web convencional donde cada solicitud responde en unos milisegundos.

Mover una VM, actualizar un clúster o desplegar Prism Central puede necesitar minutos.

Las APIs v4 de Nutanix ya utilizan un modelo de tareas asíncronas para numerosas operaciones. Una solicitud puede devolver un identificador de tarea que posteriormente se consulta hasta conocer su resultado.

La documentación de Prism v4, por ejemplo, utiliza respuestas HTTP 202 para operaciones aceptadas que todavía no han terminado y proporciona una referencia a la tarea correspondiente.

Esto encaja especialmente bien con agentes.

Agent
  │
  ├── iniciar operación
  │
  ▼
Task ID: 12345
  │
  ├── consultar estado
  │
  ├── esperar
  │
  ├── consultar estado
  │
  ▼
COMPLETED

El agente no tiene que mantener una conexión abierta mientras termina una operación.

Puede volver posteriormente, comprobar su estado y continuar con el workflow.

Del lenguaje natural a Python, Go o PowerShell

El servidor MCP también tiene una vertiente dirigida a desarrolladores.

Nutanix asegura que los asistentes pueden utilizar el conocimiento de sus APIs para generar código directamente en diferentes lenguajes y formatos.

Entre ellos:

Python
Go
Java
JavaScript
PowerShell
curl
REST
JSON

Esto tiene sentido porque el portal para desarrolladores de Nutanix ya publica ejemplos para varios de estos lenguajes dentro de la referencia v4.

Un administrador podría pedir:

Genera un script PowerShell que liste las VM
del clúster con más de 16 GB de RAM.

Mientras que un desarrollador podría solicitar:

Crea un ejemplo en Go para consultar las tareas
activas de Prism Central.

El agente dispone así de una descripción estructurada de la API en lugar de tener que deducir endpoints a partir de documentación no estructurada.

El caso realmente interesante: operaciones híbridas

Nutanix lleva años construyendo su propuesta alrededor de la nube híbrida.

Nutanix Cloud Platform puede utilizarse en centros de datos propios, entornos Nutanix Cloud Clusters y ubicaciones edge.

La propia documentación v4 describe su capa de Multi Domain Management como una forma de administrar servicios NCP desplegados en:

on-premises
     +
Nutanix Cloud Clusters
     +
edge

Aquí un agente puede tener bastante más utilidad que en un clúster aislado.

Por ejemplo:

"Comprueba si tenemos capacidad para mover
20 VM del datacenter a NC2 sin superar
el 70 % de utilización."

Resolver algo así puede exigir consultar:

• capacidad;
• CPU;
• memoria;
• almacenamiento;
• inventario de VM;
• redes;
• políticas;
• diferentes dominios.

Es precisamente el tipo de tarea donde un agente capaz de encadenar APIs puede reducir trabajo manual.

MCP no convierte automáticamente la infraestructura en autónoma

Conviene evitar, sin embargo, una interpretación exagerada del anuncio.

Que una plataforma disponga de un servidor MCP no significa que un agente pueda administrar de forma segura cualquier infraestructura sin supervisión.

MCP proporciona un mecanismo para exponer herramientas.

La seguridad final sigue dependiendo de:

identidad
+ permisos
+ diseño de herramientas
+ validación
+ límites
+ auditoría
+ aprobación humana

También aparece un problema cada vez más relevante: la prompt injection.

Si un agente consulta información externa y posteriormente dispone de herramientas capaces de modificar infraestructura, un contenido malicioso podría intentar inducirlo a ejecutar acciones no previstas.

Los controles tradicionales de RBAC reducen el impacto potencial, pero no eliminan este tipo de riesgo.

La estrategia más prudente continúa siendo aplicar el principio de mínimo privilegio y separar agentes de lectura de aquellos capaces de modificar producción.

La administración cloud puede estar entrando en una nueva etapa

Durante años, la evolución de la administración de infraestructura siguió aproximadamente esta secuencia:

GUI
 ↓
CLI
 ↓
API
 ↓
Infrastructure as Code
 ↓
automatización
 ↓
agentes

MCP no sustituye las capas anteriores.

En realidad depende de ellas.

El agente funciona porque existe una API estable. La API es segura porque existe autenticación y RBAC. Las acciones pueden reproducirse porque existe automatización.

Lo nuevo es la interfaz situada encima.

Un administrador ya no necesita necesariamente conocer el endpoint exacto para empezar a investigar un problema. Puede expresar la intención y dejar que el agente determine qué herramientas consultar.

Eso puede reducir considerablemente el tiempo dedicado a operaciones rutinarias.

También aumenta el riesgo si esa abstracción hace que el usuario olvide lo que realmente ocurre por debajo.

Por eso el enfoque de Nutanix resulta significativo: introducir agentes sin crear una vía que eluda los mecanismos tradicionales de gobierno de infraestructura.

La verdadera prueba llegará cuando estas herramientas empiecen a utilizarse de forma habitual sobre entornos de producción.

Preguntas frecuentes

¿Qué ha lanzado Nutanix?

Nutanix ha anunciado un servidor MCP open source para Nutanix Cloud Platform que permite conectar agentes y asistentes de IA con la plataforma mediante las APIs Prism v4.

¿Qué asistentes pueden utilizarlo?

Nutanix menciona GitHub Copilot, Claude Code y Cursor, aunque el servidor puede utilizarse con otros agentes compatibles con Model Context Protocol.

¿Puede un agente modificar la infraestructura?

Puede ejecutar las operaciones para las que disponga de autorización. El acceso está sujeto a las capacidades y controles de la API Prism v4 y al RBAC configurado en Nutanix.

¿Es seguro permitir que una IA administre producción?

MCP por sí solo no garantiza la seguridad. Nutanix añade RBAC, auditoría, limitación de llamadas y supervisión humana, pero las organizaciones deben seguir aplicando mínimo privilegio y controles específicos para operaciones sensibles.