Servidor MCP de Atlassian: configuración, lista de permitidos y acceso seguro

Qué es el servidor MCP de Atlassian

ElServidor MCP de Atlassian es el servidor MCP de Atlassian Rovo: un punto de conexión remoto del Model Context Protocol que expone Jira, Confluence y Compass como herramientas que un agente de IA puede invocar. Se encuentra en https://mcp.atlassian.com/v1/mcp y se autentica mediante OAuth2.

Abarca tres productos:

La documentación describe la interfaz en términos de búsqueda de incidencias, lectura de páginas y creación de tickets, en lugar de nombrar las funciones de las herramientas. La lista definitiva es la que aparece en la pestaña Herramientas después de autorizar, ya que la pasarela refleja la lista actualizada en tiempo real.

Al ser remoto, no hay nada que ejecutar localmente: ni contenedores Docker, ni procesos npx por portátil. Apuntas un cliente MCP a una URL y te autenticas, lo cual es el atractivo de los servidores MCP remotos en general.

Qué hacen realmente los agentes con él

Los usos interesantes encadenan herramientas entre productos:

• Triaje de sprints. Buscar incidencias abiertas en Jira, agrupar duplicados cercanos, extraer la especificación vinculada en Confluence de cada grupo para comprobar si el requisito ha cambiado y crear un ticket consolidado.
• Redacción de informes de incidentes. Leer el incidente en Jira, buscar el manual de procedimientos en Confluence, extraer el servicio responsable de Compass y redactar un post-mortem citando los tres.
• De especificación a ticket. Lee una especificación de Confluence, divídela en tickets de Jira con criterios de aceptación extraídos de la página y vincula cada uno a su fuente.
• Búsqueda de propiedad. Llega una pregunta sobre un servicio que nadie reconoce. El agente consulta Compass para identificar el componente y responde basándose en su página de arquitectura en Confluence.

La distinción importante no es solo entre lectura y escritura, sino entre público y sensible. Leer un issue de Jira es inofensivo. Crear uno es reversible. Leer Confluence requiere la mayor precaución: es donde las empresas guardan presentaciones para la junta, bandas salariales, postmortems con nombres de personas y arquitectura de seguridad. Un agente de solo lectura con acceso ilimitado a Confluence tiene un radio de impacto mayor que un agente con capacidad de escritura limitado a un solo proyecto de Jira.

Esa asimetría es específica de Atlassian, y es la razón por la que "desactivar las herramientas de escritura" es un consejo incompleto en este caso.

Por qué la conexión directa falla a escala de equipo

Que un ingeniero integre esto en Cursor está bien. Treinta ingenieros más un agente de soporte y uno de documentación es un problema distinto.

La lista de permitidos es una decisión a nivel de toda la organización. Se configura por organización, no por equipo. Quien tenga permisos de administrador de la organización en admin.atlassian.com decide si esta integración existe o no. Si conectas herramientas de forma improvisada, acumularás dominios permitidos que nadie revisa.

Sin rastro de auditoría de la intención. Atlassian registra que se realizó una llamada a la API desde la cuenta de un usuario. No registra que tu agente de triaje la realizó mientras actuaba según una instrucción de un hilo de Slack. Cuando aparece un ticket que nadie recuerda haber creado, no hay forma de reconstruir la cadena de eventos.

El alcance de lectura de Confluence es "todo lo que el usuario puede ver". Los permisos por usuario son el diseño correcto, pero la mayoría de los entornos tienen permisos de espacio en Confluence demasiado permisivos por inercia histórica. Lo que un usuario puede ver suele ser mucho más de lo que una tarea requiere, y el agente no puede distinguir la diferencia.

La inyección de prompts tiene dónde aterrizar. Las descripciones de Jira y las páginas de Confluence son texto que un agente lee y que alguien más pudo haber escrito. Un issue enviado por un usuario externo a través de un portal de servicio, que contiene instrucciones, leído durante el triaje con acceso a Confluence activo en la misma sesión: ese es un camino desde una entrada no confiable hacia una salida sensible. El fallo no es que el agente se haya comportado mal, sino que sus permisos eran más amplios que su tarea.

Ninguna de estas son razones para evitar el servidor. Son razones para colocar un plano de control delante de él, que es para lo que sirve un pasarela MCP .

Try it yourself.

Spin up a TrueFoundry account, allowlist your domain in Atlassian once, and give your team governed Jira and Confluence access.

Get started free

Paso 0: incluir TrueFoundry en la lista de permitidos de Atlassian

Este es el paso que bloquea a los equipos, por lo que va primero. Es un requisito previo del lado de Atlassian y ninguna configuración de TrueFoundry puede sustituirlo.

Necesitas: permiso para añadir servidores MCP en TrueFoundry, una organización de Atlassian Cloud con Jira, Confluence o Compass, y acceso de administrador de la organización en admin.atlassian.com.

En Atlassian Admin, selecciona tu organización y abre Apps → AI settings → Rovo MCP server. En Allowed domains, añade el dominio de tu plano de control de TrueFoundry:

https://<tfy-control-plane-base-url>/**

No hay ningún cliente OAuth que crear. Atlassian gestiona el registro dinámico de clientes para los dominios incluidos en la lista de permitidos. Para la mayoría de los servidores MCP remotos autorregistrados, tendrías que crear una aplicación OAuth en el portal del proveedor, establecer un URI de redirección y almacenar un ID de cliente y una clave secreta. Aquí no es necesario; la entrada en la lista de permitidos es establece la relación de confianza.

La lista de permitidos es tu interruptor de emergencia. Eliminar el dominio revoca las nuevas conexiones OAuth. Detener esta integración a nivel de toda la organización es un cambio único en Atlassian Admin, independiente de la pasarela. Pocas integraciones te ofrecen un control tan limpio; anota dónde se encuentra.

Una advertencia sobre la red: si Lista blanca de IP de Atlassian está habilitada, permita también el tráfico desde el entorno donde TrueFoundry se conecta al servidor MCP remoto.

Conexión del servidor MCP de Atlassian a través de TrueFoundry

Paso 1: abra el selector. En TrueFoundry, abra MCP Gateway, haga clic en Añadir servidor MCPy seleccione Atlassian.

Este es no es el flujo del catálogo de MCP gestionados por TrueFoundry, donde solo proporciona un nombre y la plataforma se encarga de todos los campos. Atlassian requiere valores explícitos, ya que la relación de confianza proviene de la lista blanca y no de credenciales almacenadas en la plataforma.

Paso 2: configure el servidor. Utilice estos valores:

Active Datos de autenticación y seleccione la pestaña OAuth2 . Como su dominio está en la lista blanca, no necesita un ID de cliente ni una clave secreta; déjelos vacíos.

Paso 3: añada colaboradores. Añade los usuarios o equipos que deban utilizar las herramientas de Atlassian. Asigna Gestor del servidor MCP a los administradores y Usuario del servidor MCP a los consumidores.

Paso 4: guardar y autorizar. Haz clic en Añadir servidor MCP. A continuación, cada usuario abre la sección Herramientas y hace clic en Conectar ahora para completar el OAuth de Atlassian. Las herramientas aparecerán entonces y podrán probarse desde el Entorno de pruebas de agentes.

Cómo funciona realmente la autenticación

TrueFoundry separa la autenticación de entrada —cómo se identifica un cliente ante la pasarela— de la autenticación de salida, es decir, cómo se identifica la pasarela ante Atlassian. Ambas capas son independientes.

Entrada —cuatro métodos admitidos:

Hay una advertencia importante: los tokens de cuenta virtual otorgan el mismo acceso a todas las solicitudes, por lo que no pueden reflejar los permisos de usuario específicos de Atlassian; esto reduce todo el modelo de permisos a lo que esa única identidad pueda alcanzar. Utilice un PAT o un token de IdP para la entrada.

Salida —para Atlassian, esto es OAuth2. Cada usuario autoriza su propia cuenta mediante Conectar ahora, y TrueFoundry gestiona el consentimiento, el almacenamiento de tokens y la actualización, inyectando tokens por usuario en cada llamada. TrueFoundry nunca recibe las credenciales de Atlassian.

El efecto práctico, explicado claramente en la documentación: cada usuario opera con sus permisos existentes de Jira, Confluence y Compass. No existe ninguna cuenta de servicio compartida con acceso de lectura a todo el inquilino de Confluence, y cuando se revoca el acceso de alguien a Atlassian, el alcance de su agente desaparece con él.

Los usuarios se autentican dos veces: primero en la pasarela y luego en Atlassian. Eso es lo que hace posible la atribución por usuario.

Delimitar las herramientas antes de publicar

ElHerramientas La pestaña enumera todo lo que expone el servidor.

Interruptores por herramienta. Desactiva una herramienta y se omitirá por completo de tools/list; los clientes nunca la verán y no podrá ser invocada. Esto no es un filtrado a nivel de prompt. Los cambios se guardan inmediatamente con un Ajustes de herramienta actualizados aviso.

Para Atlassian, la medida más valiosa no suele ser "deshabilitar todas las escrituras". Es deshabilitar las herramientas de Confluence para los agentes que solo trabajan en Jira. Un agente de triaje de sprints necesita buscar en Jira y leer incidencias, no la capacidad de buscar en todos los espacios de Confluence del inquilino; y una herramienta que no puede llamar es una que ninguna descripción de incidencia malintencionada puede convencerle de ejecutar.

Habilitar nuevas herramientas por defecto. Esto decide qué sucede cuando Atlassian lanza una nueva herramienta. Si está sobre, las nuevas herramientas aparecen automáticamente y tu superficie de capacidades crece por sí sola. Si está off, solo estarán disponibles las herramientas que hayas habilitado explícitamente. Para un servidor que abarca tres productos con diferentes perfiles de sensibilidad, es más seguro tenerlo desactivado.

Acción masiva. Convierte cada fila en casillas de verificación con Seleccionar todo, para configurar rápidamente una lista de permitidos seleccionada.

Haz clic en el lápiz de cualquier herramienta para modificar cómo se presenta al modelo:

Modal de edición de herramienta con un campo de anulación de descripción y un selector de anotaciones de herramientas MCP que ofrece Ninguna, Solo lectura y Destructiva

ElDescripción (hasta 20.000 caracteres) guía la selección de herramientas cuando la redacción original es ambigua; es útil en Jira y Confluence, donde "buscar" puede significar dos cosas distintas. Anotaciones de herramientas MCP marca una herramienta Solo lecturaoDestructiva, estableciendo readOnlyHint o destructiveHint. Realizar las anotaciones correctamente es lo que permite que las políticas de aprobación que aparecen a continuación controlen toda una categoría de herramientas sin tener que nombrarlas una por una.

Quién puede hacer qué: roles de colaborador

El control de acceso se aplica a usuarios, equipos o cuentas virtuales en dos dimensiones: a qué servidores puede acceder una identidad y qué herramientas puede invocar.

Cajón de actualización del servidor MCP que muestra la sección de colaboradores con los roles de Administrador de servidor MCP y Aprobador de servidor MCP asignados

‍