Atlassian MCP + AWS Kiro
2026-09-19 · Por Alvaro Jesús Hernández Arteaga
Reducir el número de herramientas en las que trabaja tu equipo de Operaciones no es un lujo: es una decisión de arquitectura.
Imagina un ticket que llega a las 2 a.m.: latencia elevada en un servicio productivo. El analista de guardia abre Jira para ver el reporte, cambia a Confluence para buscar el runbook del servicio, cambia a la consola de AWS para revisar CloudWatch, y cambia una vez más al editor para escribir la remediación. Cuatro sistemas, cuatro sesiones de contexto, y el reloj del SLA corriendo en todas al mismo tiempo.
Ese patrón no es un caso extremo — es el flujo normal de atención de tickets en la mayoría de los equipos de Operaciones y DevOps. Y como líder, probablemente ya lo notas, aunque no lo midas con ese nombre: retrabajo, escalaciones que tardan más de lo necesario, y un equipo que reparte su atención entre pestañas en lugar de resolver.
El problema no es la falta de herramientas — es la fragmentación entre ellas
Cada sistema que tu equipo usa para atender un ticket resuelve bien su parte, pero ninguno conecta con el siguiente. La coordinación entre Jira, Confluence y el entorno de desarrollo queda a cargo de la memoria del analista, no del sistema.
La decisión: conectar el Remote MCP Server de Atlassian a AWS Kiro, el IDE de IA de AWS, mediante el Model Context Protocol. El servidor de Atlassian expone Jira y Confluence con autenticación OAuth y permisos granulares por sitio; Kiro lo consume como cualquier otro servidor MCP, declarado en .kiro/settings/mcp.json. A partir de ahí, tu equipo consulta tickets, actualiza su estado y busca en la base de conocimiento de Confluence sin salir del entorno donde ya investiga incidentes y escribe remediaciones — el mismo entorno donde, si ya usas el power de AWS DevOps Agent, correlacionas métricas de CloudWatch y X-Ray para llegar a una causa raíz.
Los beneficios se sienten en el día a día del equipo. El triage deja de requerir cuatro sesiones abiertas: el contexto del ticket, el runbook y el código conviven en la misma sesión de trabajo. La trazabilidad deja de depender de que alguien copie el número de ticket a mano en el mensaje de commit. Y la gobernanza no se pierde en el camino: Kiro te deja decidir con autoApprove qué acciones se ejecutan sin fricción y con disabledTools cuáles quedan fuera del alcance del agente — el control se declara, no se asume.
Las consecuencias que vale la pena anticipar
Integrar Jira a tu IDE no elimina la necesidad de un flujo de aprobación para escrituras automáticas — lo hace más visible. Antes de habilitar auto-aprobación en acciones que modifican tickets, define con tu equipo qué nivel de autonomía le das al agente y qué queda sujeto a revisión humana. La superficie de acceso depende de los permisos que otorgues a nivel de tu sitio de Atlassian Cloud, no solo de la configuración en Kiro — vale la pena revisarlos con quien administra esa cuenta antes de habilitar el servidor para todo el equipo. Y como con cualquier cambio de herramienta, la adopción real toma más que una guía de instalación: toma que el equipo confíe en que el flujo nuevo no le añade un paso más a memorizar.
Reducir el ambiente de trabajo de tu equipo no es acumular menos apps por estética. Es diseñar el flujo de atención de tickets alrededor de una sola pregunta: ¿dónde necesita estar tu equipo cuando resuelve un problema real?
#DevOps #AWS #Kiro #MCP #Atlassian
