MCP CloudOps Demo

Una demo gratuita, pública y orientada a portafolio del Model Context Protocol (MCP) que muestra cómo un cliente de IA puede descubrir y usar capacidades de CloudOps sin necesidad de una suscripción real de Azure, clave de API ni credenciales de producción.

El servidor expone herramientas, recursos y prompts respaldados por datos deterministas de infraestructura ficticia estilo Azure. Está diseñado para ser fácil de clonar, ejecutar localmente, inspeccionar con MCP Inspector, contenerizar y, más adelante, ampliar con integraciones reales de Azure o GitHub.

Seguridad: este repositorio nunca se conecta a infraestructura real por defecto. Incluso la capacidad de reinicio es una simulación.

Qué demuestra esto

Un chatbot normal solo conoce lo que está en su contexto de conversación. Un cliente habilitado para MCP también puede descubrir capacidades estructuradas expuestas por un servidor MCP.

En esta demo, el cliente puede:

• descubrir servidores de producción y staging;

• inspeccionar el estado y la utilización de los servidores;

• correlacionar incidentes, despliegues y registros;

• leer el inventario de infraestructura como recursos MCP;

• usar prompts reutilizables de investigación de incidentes;

• solicitar una acción operativa simulada con confirmación explícita.

Related MCP server: mcp-azure-toolkit

Arquitectura

flowchart LR
    U[User] --> C[MCP-compatible AI client]
    C <-->|MCP over stdio| S[MCP CloudOps Demo Server]

    S --> T[Tools]
    S --> R[Resources]
    S --> P[Prompts]

    T --> D[(Fake Azure-style JSON data)]
    R --> D
    P --> C

    T --> T1[list_servers]
    T --> T2[get_server_health]
    T --> T3[get_recent_deployments]
    T --> T4[get_open_incidents]
    T --> T5[search_logs]
    T --> T6[restart_demo_service]

También hay un diagrama más grande disponible en docs/architecture.md.

Primitivas MCP utilizadas

Herramientas

Recursos

Prompts

Escenario de demostración

Supongamos que el usuario pregunta:

¿Qué servidores de producción están en mal estado o bajo presión de recursos?

Un cliente MCP puede descubrir y llamar a list_servers(environment="prod"), ver que api-prod-02 está degradado con CPU alta y, a continuación, decidir llamar a get_server_health o inspeccionar incidentes y registros.

Una pregunta de seguimiento podría ser:

Investiga el problema que afecta a payments-api y dime si está relacionado con un despliegue.

El cliente puede combinar múltiples capacidades MCP:

User request
   |
   v
get_open_incidents("payments-api")
   |
   v
list_servers("prod")
   |
   v
get_server_health("api-prod-02")
   |
   v
get_recent_deployments(service="payments-api")
   |
   v
search_logs(service="payments-api")
   |
   v
AI correlates evidence and explains the likely cause

Esta es la propuesta de valor central de MCP: el modelo puede trabajar con capacidades externas estandarizadas en lugar de tener cada integración codificada de forma fija en la aplicación de chat.

Estructura del repositorio

mcp-cloudops-demo/
├── .github/
│   └── workflows/
│       └── ci.yml
├── docs/
│   └── architecture.md
├── examples/
│   └── prompts.md
├── src/
│   └── mcp_cloudops/
│       ├── data/
│       │   ├── deployments.json
│       │   ├── incidents.json
│       │   ├── logs.json
│       │   └── servers.json
│       ├── prompts/
│       │   └── cloudops.py
│       ├── resources/
│       │   └── cloudops.py
│       ├── tools/
│       │   └── cloudops.py
│       ├── web/
│       │   ├── app.py
│       │   ├── scenario.py
│       │   └── static/
│       │       ├── index.html
│       │       ├── styles.css
│       │       └── app.js
│       ├── server.py
│       └── store.py
├── tests/
│   ├── test_data_relationships.py
│   └── test_store.py
├── Dockerfile
├── docker-compose.yml
├── LICENSE
├── pyproject.toml
└── README.md

Requisitos

• Python 3.11 o superior

• pip, uv u otro gestor de paquetes de Python

• Opcional: Docker

• Opcional: un cliente compatible con MCP o MCP Inspector

Inicio rápido con Python

Clona el repositorio y crea un entorno virtual:

git clone https://github.com/BozyBonifacio/mcp-cloudops-demo.git
cd mcp-cloudops-demo
python -m venv .venv

Actívalo.

Linux/macOS:

source .venv/bin/activate

Windows PowerShell:

.\.venv\Scripts\Activate.ps1

Instala el proyecto:

python -m pip install -e '.[dev]'

Ejecuta el servidor MCP sobre stdio:

mcp-cloudops-demo

El proceso esperará a que un cliente MCP se comunique a través de stdin/stdout. Eso es lo esperado.

Guía detallada de ejecución en Windows

Desde PowerShell:

git clone https://github.com/BozyBonifacio/mcp-cloudops-demo.git
cd mcp-cloudops-demo
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"
mcp-cloudops-demo

Si PowerShell bloquea la activación del entorno virtual, permite los scripts solo para la sesión de terminal actual:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\.venv\Scripts\Activate.ps1

Cuando mcp-cloudops-demo se inicia y parece estar inactivo, eso es lo esperado. Esta demo usa MCP sobre stdio y espera a un cliente MCP en lugar de abrir una página web. Pulsa Ctrl+C para detenerlo.

Demo de portafolio basada en navegador

La forma más fácil de demostrar el proyecto es ahora la interfaz de navegador integrada. No requiere ninguna clave de API de LLM de pago y actúa como un cliente MCP real: el backend de FastAPI inicia el servidor MCP local sobre stdio, descubre sus capacidades, llama a las herramientas MCP y devuelve la evidencia al navegador.

Inícialo después de instalar el proyecto:

mcp-cloudops-web

Luego abre:

http://localhost:8000

La página incluye:

• una interfaz de chat estilo operador;

• prompts sugeridos de investigación de CloudOps;

• descubrimiento de capacidades MCP en tiempo de ejecución;

• un rastro MCP que muestra cada llamada a herramienta y sus argumentos;

• un flujo de trabajo determinista de investigación de incidentes que no requiere ningún servicio de IA externo;

• el comportamiento de seguridad existente para el reinicio simulado.

Un primer prompt recomendado es:

Investiga el incidente abierto que afecta a payments-api y dime la causa probable.

El backend del navegador usará MCP para llamar a múltiples herramientas como get_open_incidents, list_servers, get_recent_deployments y search_logs, y luego mostrará tanto la conclusión como el rastro de llamadas MCP.

¿Por qué chat determinista? La demo del navegador no requiere intencionadamente OpenAI, Azure OpenAI, Anthropic ni otra API de modelo de pago. Un pequeño enrutador de intenciones reconoce los escenarios de demostración incluidos mientras MCP sigue siendo responsable del descubrimiento de capacidades y la ejecución de herramientas. Más adelante puedes sustituir el enrutador por un LLM sin cambiar el contrato del servidor MCP.

Arquitectura de la demo del navegador

Browser
   |
   | HTTP /api/chat
   v
FastAPI browser backend
   |
   | MCP over stdio
   v
MCP CloudOps Server
   |
   +--> Tools
   +--> Resources
   +--> Prompts
   |
   v
Fake Azure-style JSON data

Demo del navegador con Docker

Construye e inicia el contenedor:

docker compose up --build

Luego abre:

http://localhost:8000

Detenlo con Ctrl+C y, opcionalmente, elimina el contenedor con:

docker compose down

Prueba con MCP Inspector

El SDK oficial de MCP para Python incluye herramientas de desarrollo cuando se instala con el extra de CLI.

Si tu entorno tiene disponible la CLI de MCP, ejecuta:

mcp dev src/mcp_cloudops/server.py

Luego abre la URL del Inspector que se imprime en tu terminal. Explora las pestañas Tools, Resources y Prompts.

Si mcp no está instalado como comando de CLI, instala el extra de CLI del SDK:

python -m pip install 'mcp[cli]'

Recorrido recomendado por MCP Inspector

Después de iniciar Inspector, usa esta secuencia para demostrar cómo múltiples capacidades MCP contribuyen a una sola investigación:

1. Llama a list_servers con environment = prod.

2. Llama a get_server_health con server_name = api-prod-02.

3. Llama a get_open_incidents e investiga payments-api.

4. Llama a get_recent_deployments para payments-api.

5. Llama a search_logs para el servicio/servidor afectado e inspecciona los eventos ERROR.

list_servers("prod")
        |
        v
get_server_health("api-prod-02")
        |
        v
get_open_incidents("payments-api")
        |
        v
get_recent_deployments(service="payments-api")
        |
        v
search_logs(service="payments-api")
        |
        v
AI correlates the evidence

Prompt recomendado para demo en vivo

Investiga el incidente abierto que afecta a payments-api. Determina qué servidor está afectado, su estado de salud, si un despliegue reciente se correlaciona con el incidente, qué muestran los registros y la causa más probable.

El punto clave a explicar es que el servidor MCP anuncia capacidades estandarizadas que un host compatible con MCP puede descubrir y combinar en lugar de depender de un único flujo de chatbot codificado de forma fija.

Configuración del cliente MCP en Windows

Cuando uses un entorno virtual en Windows, prefiere la ruta absoluta a su ejecutable de Python. Por ejemplo, si el repositorio está en C:\github\mcp-cloudops-demo:

{
  "mcpServers": {
    "cloudops-demo": {
      "command": "C:\\github\\mcp-cloudops-demo\\.venv\\Scripts\\python.exe",
      "args": ["-m", "mcp_cloudops.server"]
    }
  }
}

Reemplaza la ruta de ejemplo con la ubicación real de tu clon. Esto evita iniciar accidentalmente una instalación de Python diferente que no contenga las dependencias del proyecto.

Solución de problemas

Si mcp-cloudops-demo no se reconoce, activa .venv y reinstala el proyecto:

.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"

También puedes probar:

python -m mcp_cloudops.server

Si mcp no se reconoce:

python -m pip install "mcp[cli]"
mcp dev src/mcp_cloudops/server.py

Si obtienes ModuleNotFoundError: mcp_cloudops, asegúrate de estar en la raíz del repositorio, reinstala el paquete editable y verifica la importación:

python -m pip install -e ".[dev]"
python -c "import mcp_cloudops; print('mcp_cloudops import OK')"

Ejecutar pruebas

pytest

Ejecuta el linting:

ruff check src tests

Ejecutar con Docker

La imagen de Docker ahora inicia la interfaz de navegador por defecto.

docker build -t mcp-cloudops-demo .
docker run --rm -p 8000:8000 mcp-cloudops-demo

Abre http://localhost:8000.

O usa Docker Compose:

docker compose up --build

Para ejecutar el servidor MCP stdio original dentro de la imagen en su lugar:

docker run --rm -i --entrypoint mcp-cloudops-demo mcp-cloudops-demo

Ejemplo de configuración de cliente

Los hosts MCP generalmente solo necesitan el comando que inicia el servidor stdio. El formato exacto de configuración depende de tu cliente.

Una configuración local típica se ve conceptualmente así:

{
  "mcpServers": {
    "cloudops-demo": {
      "command": "python",
      "args": ["-m", "mcp_cloudops.server"]
    }
  }
}

Si el paquete está instalado en un entorno virtual, apunta el host al ejecutable de Python de ese entorno o usa el comando mcp-cloudops-demo instalado.

Prompts sugeridos

Prueba:

• Which production servers are unhealthy or under resource pressure?

• Investigate the open incident affecting payments-api.

• Did a recent deployment correlate with the current production issue?

• Show ERROR logs for api-prod-02 and explain the likely cause.

• Use the investigate_incident prompt for payments-api.

• Read infra://inventory/production and summarize capacity risks.

• Simulate restarting api-prod-02, but ask me for confirmation first.

Hay más ejemplos en examples/prompts.md.

¿Por qué datos ficticios?

Una demo pública de MCP debería poder ejecutarla cualquiera sin exponer secretos ni requerir gasto en la nube. Los fixtures JSON proporcionan:

• cero coste de infraestructura;

• comportamiento determinista para demostraciones;

• control de fuentes públicas seguro;

• pruebas automatizadas repetibles;

• un límite limpio entre las capacidades de MCP y la eventual fuente de datos real.

Ampliar la demo a Azure real

La vía de actualización más fácil es mantener las funciones orientadas a MCP y reemplazar load_json() con una capa de adaptador.

Por ejemplo:

MCP Tool
   |
   v
CloudOps service interface
   |
   +--> DemoJsonProvider
   |
   +--> AzureProvider
          |
          +--> Azure Resource Graph
          +--> Azure Monitor
          +--> Log Analytics
          +--> Azure DevOps / GitHub

Las integraciones reales potenciales incluyen:

• Azure Resource Graph para inventario de VM/recursos;

• Azure Monitor para métricas;

• Log Analytics para consultas KQL;

• Azure Update Manager para el estado de parches;

• GitHub para commits, pull requests y ejecuciones de Actions;

• Azure DevOps para pipelines e historial de despliegues.

Para una versión pública de portafolio, prefiere permisos de solo lectura y usa variables de entorno o identidad administrada en lugar de almacenar credenciales en el repositorio.

Ejemplo de escenario futuro con múltiples servidores

Una segunda versión más potente de este proyecto podría demostrar un cliente de IA correlacionando datos entre múltiples servidores MCP:

Developer
  |
  | "Why did the deployment fail?"
  v
AI / MCP Host
  |
  +--> GitHub MCP server ------> commit / pull request
  |
  +--> Azure MCP server -------> deployment status
  |
  +--> Observability MCP ------> application logs
  |
  v
Correlated incident explanation

Eso demuestra por qué un protocolo es útil: cada dominio puede exponer capacidades de forma independiente mientras el host proporciona la orquestación conversacional.

Consideraciones de seguridad

Este repositorio sigue intencionadamente varios patrones de demo segura:

• no se confirman secretos;

• no se requieren credenciales de nube;

• los datos operativos son ficticios;

• las acciones similares a escritura son simulaciones;

• el reinicio simulado requiere un parámetro explícito confirmed=true;

• GitHub Actions usa permiso de solo lectura para el contenido del repositorio;

• las pruebas verifican las relaciones de los fixtures para que las demos sigan siendo coherentes.

Si reemplazas el proveedor ficticio con infraestructura real, añade autenticación, autorización, registro de auditoría, acceso con privilegios mínimos, validación de entrada y controles de confirmación antes de exponer herramientas mutadoras.

CI

El flujo de trabajo de GitHub Actions incluido se ejecuta en pushes y pull requests y valida:

• Python 3.11;

• Python 3.12;

• linting de Ruff;

• pruebas de Pytest.

Referencias útiles de MCP

• Model Context Protocol: https://modelcontextprotocol.io/

• Official Python SDK: https://github.com/modelcontextprotocol/python-sdk

• MCP specification: https://github.com/modelcontextprotocol/modelcontextprotocol

Licencia

MIT. Consulta LICENSE.

Puntos clave para el portafolio

Al demostrar este repositorio, enfatiza estos puntos:

1. El host de IA está separado del servidor MCP.

2. El servidor anuncia capacidades en lugar de incrustar lógica de chatbot.

3. Las herramientas son acciones/consultas, los recursos son contexto direccionable y los prompts son flujos de trabajo reutilizables.

4. El mismo servidor MCP puede ser consumido por diferentes hosts compatibles.

5. El proveedor de datos ficticios puede reemplazarse sin rediseñar la interfaz MCP.

6. Las operaciones mutadoras deberían tener controles de autorización y confirmación más fuertes que las operaciones de lectura.

Construido como un ejemplo educativo de CloudOps. Todos los nombres de infraestructura, incidentes, despliegues y métricas en el conjunto de datos predeterminado son ficticios.