Cómo crear y mantener un catálogo fiable de herramientas oficiales para DevOps/Cloud/SRE con AI agents

Problema

En entornos de DevOps, SRE y Cloud, la cantidad de agentes AI, skill‑sets y MCP (Managed Cloud Platform) servers crece rápidamente. Cada equipo necesita acceder a versiones oficiales, evitar herramientas de terceros sin garantía y, sobre todo, contar con información de riesgo (write‑capability, aprobación humana, trazabilidad). Sin un catálogo centralizado, los ingenieros pierden tiempo buscando repositorios, verifican enlaces rotos manualmente y, en el peor de los casos, integran herramientas no auditadas que pueden romper pipelines o exponer credenciales.

El patrón que se repite es la falta de una fuente única y confiable que combine:

• Listado de servidores MCP oficiales (AWS, Azure, GCP, etc.).
• Skills y toolkits de agentes AI compatibles con cada plataforma.
• Metadatos de seguridad: nivel de escritura, necesidad de aprobación, evidencias y madurez.
• Mecanismo de auditoría continua para mantener la lista actualizada.

Causa

1. Fragmentación de fuentes – Los repositorios oficiales de cada proveedor están dispersos (GitHub, Azure DevOps, Google Artifact Registry). Los usuarios copian y pegan URLs sin validar su vigencia.
2. Ausencia de esquema de metadatos – La mayoría de los catálogos usan simples listas de texto. Sin campos estructurados (risk, approval, evidence) es imposible filtrar por requisitos de compliance.
3. Proceso manual de actualización – Cada cambio requiere abrir un PR, revisar enlaces y volver a publicar. En equipos con despliegues diarios, el retraso genera desalineación entre lo que está en producción y lo que está en el catálogo.
4. Falta de automatización de pruebas – No hay CI que verifique la disponibilidad de los endpoints ni que ejecute pruebas de “read‑only” contra los servidores MCP listados.

Solución

Construir un catálogo versionado en Git con un esquema YAML estandarizado y un pipeline CI que:

1. Define un modelo de entrada con campos obligatorios:

   - name: "Google Cloud Terraform ADK"
     provider: "google"
     type: "agent-skill"
     repo: "https://github.com/GoogleCloudPlatform/terraform-adk"
     risk:
       write: false
       approval_required: true
       evidence: "plan‑output.json"
       maturity: "stable"
   

2. Automatiza la validación mediante un job de GitHub Actions (o Cloud Build) que:
   • Ejecuta curl -f contra cada URL.
   • Verifica que el repositorio tenga al menos un README.md y un LICENSE.
   • Opcionalmente clona el proyecto y corre pruebas unitarias si existen.
3. Genera un índice JSON consumible por agentes AI (Claude, Copilot, etc.) para que descubran skills sin leer el YAML.
4. Implementa un instalador de una línea que descargue los skills seleccionados y los copie al directorio de skills del agente. El script debe aceptar filtros por proveedor y producto.
5. Documenta criterios de riesgo en un archivo SCORING.md que explique cómo se asignan los valores de write, approval_required y maturity. Así cualquier colaborador puede aportar de forma consistente.

Alternativas prácticas

Cuándo aplicar esta solución

• Síntomas: equipos pierden tiempo buscando herramientas, aparecen enlaces rotos en la documentación, o se detectan cambios no aprobados en pipelines de CI.
• Entornos: cualquier organización con más de dos proveedores cloud, uso de agentes AI para IaC, y requerimientos de compliance (SOC2, ISO27001).
• Exclusiones: proyectos muy pequeños (menos de 5 herramientas) donde la sobrecarga de CI no se justifica; entornos donde todas las herramientas son internas y no requieren verificación externa.

Código

#!/usr/bin/env bash
# audit_catalog.sh – verifica URLs y genera reporte JSON

set -euo pipefail

CATALOG="catalog.yaml"
TMPFILE=$(mktemp)

# Extrae todas las URLs del campo `repo`
yq e '.[] | .repo' "$CATALOG" | while read -r url; do
  if curl -fsSL --max-time 10 "$url" > /dev/null; then
    status="OK"
  else
    status="FAIL"
  fi
  echo "{\"url\":\"$url\",\"status\":\"$status\"}" >> "$TMPFILE"
done

# Agrupa resultados en JSON array
jq -s '.' "$TMPFILE" > audit_report.json
rm "$TMPFILE"
echo "Reporte generado en audit_report.json"

Verificación

1. Ejecuta ./audit_catalog.sh desde la raíz del repositorio.
2. Abre audit_report.json y confirma que todos los objetos tengan "status":"OK".
3. Si aparecen fallos, abre un PR que actualice la URL o elimine la entrada.
4. Revisa que el pipeline CI (GitHub Actions) haya pasado la fase Validate URLs.
5. Opcional: ejecuta curl -s <repo>/README.md | grep -i license para validar la presencia de licencia.

Notas adicionales

• Cache de DNS – En entornos con restricciones de red, añade --resolve a curl para evitar falsos negativos por DNS interno.
• Rate limiting – Algunos proveedores (GitHub, Azure DevOps) limitan peticiones anónimas. Usa un token de acceso con Authorization: token $GH_TOKEN cuando sea necesario.
• Versionado de skills – Incluye siempre el número de versión o commit SHA en el campo repo (.../tree/v1.2.3). Así los agentes pueden bloquear actualizaciones inesperadas.
• Rollback rápido – Mantén una rama stable del catálogo que contenga solo entradas con maturity: stable. En caso de incidente, cambia el pipeline a esa rama.
• Colaboración externa – Si aceptas contribuciones de la comunidad, habilita un CODE_OF_CONDUCT.md y un CONTRIBUTING.md que describan cómo llenar los campos de riesgo. Esto reduce ruido en los PR y mantiene la calidad del catálogo.

Con este enfoque, el catálogo pasa de ser una lista estática a una fuente viva de confianza, alineada con los requisitos de seguridad y con la capacidad de escalar a medida que aparecen nuevos MCP servers y agent skills. La automatización de auditoría y la estandarización de metadatos garantizan que los equipos de DevOps y SRE siempre trabajen con herramientas verificadas, reduciendo tiempo de búsqueda y minimizando riesgos operacionales.