Claude para Jira Service Management: cuatro herramientas JSM, ninguna para tickets

Atlassian hizo lo que todos los demás siguen prometiendo

Construyo agentes de IA en eesel, lo que en la práctica significa que me dedico a leer las especificaciones de herramientas de otras personas. La pregunta "¿puedo apuntar Claude a nuestro helpdesk" ha sido, con diferencia, la más común en mi bandeja de entrada este año. La respuesta suele ser alguna variante de no.

Cuando revisé Claude para Zendesk, lo que Zendesk había lanzado era un cliente MCP, no un servidor. Freshdesk está detrás de un programa de acceso anticipado. Gorgias no tiene ni siquiera un listado en su marketplace para esto. Help Scout sí lanzó un servidor real, y luego lo hizo de solo lectura a propósito.

Atlassian simplemente lo construyó. En la página de Rovo MCP hay una cuadrícula de clientes de IA, y Claude es uno de cuatro, junto a Cursor, VS Code y ChatGPT. El texto lo dice directamente: mantente en el flujo, "ya sea que necesites contexto de Atlassian en Claude". Un proveedor que apunta a sus propios clientes hacia el modelo de otro, a propósito, en su propia página de marketing.

El modelo de acceso también es inusualmente generoso. El propio FAQ de Atlassian dice "Todos los clientes de Atlassian Cloud tienen acceso". Tu plan solo cambia el rendimiento: los sitios Free obtienen 500 llamadas por hora, Standard 1.000, y Premium o Enterprise obtienen 1.000 más 20 por usuario, hasta un tope de 10.000. Tampoco hace falta una suscripción a Rovo, porque, como dice Atlassian, el servidor "no es un modelo de IA, es una capa de integración".

Así que este artículo no es una crítica destructiva. Es lo que me habría gustado que alguien me dijera antes de pasarme una tarde esperando una mesa de servicio y encontrándome en su lugar un rastreador de tareas.

Las cuatro formas de conectar Claude a Jira Service Management

Hay cuatro rutas. Se ordenan según un eje que importa más que todos los demás juntos: si la cosa puede poner palabras delante de la persona que levantó el ticket.

La forma de ese gráfico es todo el argumento. La ruta instantánea, oficial y gratuita es la que no puede responder a un solicitante. El mismo intercambio que encontré en Help Scout, aunque Atlassian llega a él desde otra dirección. Help Scout lanzó deliberadamente algo de solo lectura. Atlassian lanzó escritura, y luego nunca la apuntó hacia la mesa de servicio.

Ruta 1: el servidor oficial, de principio a fin

El endpoint es una sola cadena:

https://mcp.atlassian.com/v1/mcp/authv2

Una advertencia, antes de que copies una configuración antigua de algún lado. Atlassian eliminó el transporte SSE heredado: a partir del 30 de junio de 2026, https://mcp.atlassian.com/v1/sse ya no es compatible. Esa fecha ya pasó. Así que si heredaste una configuración del blog de un colega de la primavera, está muerta, y el síntoma se parecerá más a un fallo de autenticación que a una desactivación.

Para Claude Code es un solo comando:

claude mcp add --transport http atlassian https://mcp.atlassian.com/v1/mcp/authv2

Luego /mcp para ejecutar el flujo de OAuth. En Claude Desktop la ruta es Settings, Extensions, Browse extensions, Plugins, buscar Atlassian. Y en claude.ai, el listado de Atlassian está en el directorio de conectores, descrito como lectura y escritura, construido por Atlassian.

Un detalle de implementación hace tropezar a la gente en la primera llamada. Cada herramienta quiere un cloudId, y la forma de obtenerlo es getAccessibleAtlassianResources, que Atlassian describe como una llamada inicial obligatoria para cualquier herramienta. Sáltatela, deja que Claude dispare directo a searchJiraIssuesUsingJql, y el error que regresa se lee como un problema de permisos. No lo es.

Lo otro que vale la pena saber el primer día: Claude llega a tu servidor MCP desde la infraestructura de Anthropic, nunca desde tu portátil. Esto es cierto incluso en Claude Desktop. Así que si tu sitio de Atlassian está detrás de una lista blanca de IP, las llamadas a herramientas fallarán mientras la pantalla de consentimiento de OAuth sigue apareciendo sin problema, que es probablemente el modo de fallo más confuso que existe.

Ruta 2: las cuatro herramientas JSM, y la barrera de token delante de ellas

Ahora, la parte que me hizo parar y leer la página dos veces.

Atlassian publica alrededor de 46 herramientas, repartidas en 13 grupos de permisos. Jira tiene 14. Confluence tiene 12, Bitbucket también 12, Compass 10. Jira Service Management tiene cuatro:

Cada una de ellas vive en el lado operativo, la parte de JSM que desciende de las alertas de guardia. Ninguna toca la mesa de servicio. No hay ninguna herramienta publicada para solicitudes, tipos de solicitud, colas, SLA, aprobaciones, clientes del portal o configuración del portal.

Y hay una segunda barrera delante incluso de esas cuatro. La página de herramientas compatibles de Atlassian indica que las herramientas JSM "solo admiten autenticación por token de API" y "solo están disponibles si la autenticación por token de API ha sido habilitada por el administrador de tu organización". Mientras tanto, OAuth es el flujo predeterminado, y el recomendado. El resultado práctico para la mayoría de la gente, entonces: un inicio de sesión normal de Claude no muestra ninguna de las herramientas JSM, y nada en la interfaz explica por qué.

Compass, por cierto, tiene la regla opuesta: solo OAuth, sin token de API. Bitbucket quiere un token de API y un espacio de trabajo vinculado. Tres productos, tres reglas de autenticación distintas, todas dentro de un mismo servidor.

Lo que realmente puedes alcanzar en una mesa de servicio

Nada de esto significa que Claude sea ciego a tus tickets. Un proyecto de JSM es un proyecto de Jira por debajo, así que las herramientas genéricas de Jira funcionan sobre él. getVisibleJiraProjects, getJiraIssue, searchJiraIssuesUsingJql, getTransitionsForJiraIssue, transitionJiraIssue, editJiraIssue y addCommentToJiraIssue funcionan todas perfectamente sobre elementos de trabajo de JSM.

Esa distinción importa más de lo que parece. La propia documentación de Atlassian es contundente sobre lo que aporta un tipo de solicitud: "Si creas un elemento de trabajo sin un tipo de solicitud, tus solicitudes no tendrán acceso a todas las funciones de Jira Service Management." Claude está mirando la capa de Jira debajo de la mesa de servicio, no la mesa de servicio. Donde tus agentes ven una solicitud con un reloj de SLA, una cola, un portal y un cliente adjunto, Claude ve un elemento de trabajo.

La versión más aguda de ese hueco son los comentarios. En la API de la mesa de servicio, la visibilidad para el cliente se reduce a exactamente un booleano en el cuerpo del comentario:

POST /rest/servicedeskapi/request/{issueIdOrKey}/comment
{ "body": "Hello there", "public": true }

public: true es una respuesta que el solicitante ve en el portal. public: false es una nota interna, solo para agentes. Sin endpoint separado, sin objeto de visibilidad, solo el indicador. Y la herramienta MCP addCommentToJiraIssue no lleva un parámetro equivalente en su descripción publicada, lo que significa que Claude no tiene forma de indicar si las palabras que escribe están dirigidas al solicitante. En una mesa de TI eso no es una carencia menor. Es la diferencia entre una nota a tu colega y un correo a un director.

Vale la pena saberlo si más adelante tomas el camino de la API: el recurso de comentarios de la mesa de servicio solo expone GET y POST. Sin PUT, sin DELETE. Retirar un comentario significa bajar a la API de la plataforma Jira en /rest/api/3/issue/{id}/comment/{id}, con el permiso Editar comentarios propios o Eliminar comentarios propios. Planifica cómo deshacer antes de necesitarlo.

Ruta 3: la API REST de la mesa de servicio, si la construyes tú mismo

Si quieres el comportamiento consciente de colas, de SLA y visible para el cliente, lo escribes tú mismo contra /rest/servicedeskapi/. Eso es un proyecto real, no un fin de semana, y hay tres cosas que darán forma al diseño más de lo que esperarías.

Los límites de tasa son tres sistemas a la vez, y Atlassian dice que tu integración "debe manejar los tres". Una cuota horaria basada en puntos, límites de ráfaga por segundo, y luego límites de escritura por incidencia encima. El Global Pool predeterminado es de 65.000 puntos por hora compartidos entre inquilinos; un pool por inquilino va de 65.000 en Free hasta 150.000 más 30 por usuario en Enterprise, con tope de 500.000. Los valores predeterminados de ráfaga están en 100 solicitudes por segundo en GET y POST, y 50 en PUT y DELETE. Las escrituras por incidencia tienen un tope de 20 en dos segundos y 100 en treinta. Y un endpoint es dramáticamente más estrecho que todos los demás: GET /servicedeskapi/servicedesk/{id}/customer está limitado a 5 solicitudes por segundo, y será el primer muro contra el que choques en cualquier relleno masivo de clientes.

Fallos silenciosos de permisos. Atlassian documenta que en GET /request/{id}/comment, "no se muestra ningún error de permisos si, por ejemplo, el usuario no tiene acceso a la mesa de servicio o a la solicitud; el método simplemente devuelve una respuesta vacía". Así que un agente que no lee comentarios, y luego concluye que no había ninguno, termina respondiendo con total confianza a la pregunta equivocada.

El acceso a la base de conocimiento es solo búsqueda. GET /rest/servicedeskapi/knowledgebase/article devuelve artículos que coinciden con una consulta, por mesa de servicio o en todas ellas, y query es obligatorio. Nada en ese espacio de nombres recupera el cuerpo completo de un artículo, así que fundamentar respuestas en tu base de conocimiento implica un segundo viaje a la API de Confluence. Lo positivo: ambos endpoints de base de conocimiento están exentos de las reglas de acceso de aplicaciones, a diferencia de cualquier endpoint de solicitudes y comentarios.

Lo que cuesta realmente una respuesta de JSM

Aquí es donde el límite de solo lectura se vuelve financieramente interesante. Los tokens son baratos, y lo que compran es limitado.

Una respuesta bien fundamentada llega a unos 12.000 tokens de entrada una vez que has extraído el ticket, las transiciones y dos páginas de Confluence, más unos 700 tokens de salida en el camino de vuelta. En Claude Sonnet 5 a 2 $ y 10 $ por millón, eso son unos 3,1 centavos. Más cerca de 1,3 centavos una vez que el caché de prompts hace su trabajo, a 0,20 $ por millón en lecturas en caché. En Claude Opus 5 a 5 $ y 25 $, la misma respuesta se acerca a 7,8 centavos.

Ahora las comparaciones. El propio agente virtual de Atlassian incluye 1.000 conversaciones asistidas al mes, y luego cobra desde 0,30 $ cada una a partir de ahí, y una conversación que se empareja con una intención y luego se escala a un humano se sigue cobrando. Los créditos de Rovo son un medidor completamente aparte: Standard obtiene 25 por usuario al mes, Premium 70, Enterprise 150. Las herramientas beta de Teamwork Graph en el servidor MCP son gratis hoy, pero Atlassian ha dicho que "se facturarán a un mínimo de 1 crédito de Rovo por llamada" en disponibilidad general, con 90 días de aviso previo.

Una advertencia antes de tomar cualquier cifra por conversación al pie de la letra, de parte de un gestor de TI que llevó el tema directamente al equipo de producto:

"One example: virtual agent will count a ticket as "successfully deflected" if the user gives up responding and it auto closes. That's not a successful deflection, that's an awful user experience."

u/Goose-tb, r/ITManagers

Vale la pena comprobar eso contra cualquier herramienta que elijas, la nuestra incluida. Una tasa de desvío que cuenta el abandono como un éxito está midiendo lo equivocado, y es la cifra que más probablemente te citen de vuelta en una reunión de renovación.

Introduce tus propios números:

La lectura honesta de esas tres cifras: la columna de tokens es la más barata porque es la que menos compra. Sin canal de respuestas, sin indicador de visibilidad, sin enrutamiento de colas, sin conciencia de SLA, y sin ninguna manera de probarse a sí misma antes de encontrarse con un solicitante real. Comparar eso con un precio por solicitud es comparar un asistente de investigación con un agente. Útil. No el mismo trabajo.

El lado del administrador, y por qué dirá acceso denegado

Cuatro cosas separadas tienen que ser todas ciertas antes de que una sola llamada a herramienta llegue a destino. Cada una falla de forma distinta.

1. El dominio de IA tiene que estar permitido. Atlassian trae una lista predeterminada de dominios de socios de IA, incluidos Claude y ChatGPT. Los administradores pueden permitirla o bloquearla, pero Atlassian es explícito: "No puedes bloquear dominios individuales. Solo puedes permitir o bloquear la lista completa de dominios." Lo que no deja forma de permitir Claude y rechazar todo lo demás.
2. La IP tiene que pasar la lista blanca, y esta es traicionera, porque "la pantalla de consentimiento de OAuth 2.1 puede seguir apareciendo para usuarios que se conectan desde IP bloqueadas, pero las llamadas a herramientas fallarán". La conexión se ve exitosa justo hasta el momento en que no hace nada.
3. El método de autenticación tiene que estar permitido. La autenticación por token de API es un interruptor a nivel de organización, y ese interruptor es lo que decide si las herramientas JSM existen para ti en absoluto. El bloqueo de dominios, por cierto, no se aplica a las conexiones por token de API.
4. La salida de red tiene que alcanzar *.atlassian.net, ya que el servidor renderiza widgets interactivos de Jira y Confluence dentro del cliente de IA mediante iframes.

Además de todo eso, una pestaña de Permisos ahora permite a los administradores de la organización permitir o bloquear Lectura, Escritura y Búsqueda de forma independiente por aplicación, y Atlassian dice que "tendrá prioridad sobre la configuración en Connected Apps". También hay un interruptor de "Aplicar a futuras incorporaciones". Que, en silencio, significa que los permisos añadidos recientemente pueden heredar un permiso sin que nadie los revise. Si eres la persona que aprueba las revisiones de acceso, vale la pena echarle un vistazo a ese interruptor.

Dos datos de cumplimiento para tu equipo de seguridad antes de que se les ocurra preguntar. El servidor no almacena ni cachea ningún contenido de Jira o Confluence, y funciona estrictamente dentro de los permisos del usuario con sesión iniciada, lo cual es un mejor estándar que el de la mayoría de los conectores. Pero Atlassian indica que "actualmente no admite los requisitos de FedRAMP o HIPAA", y es solo Cloud, sin ninguna vía de Data Center o Server publicada. Para muchas mesas de servicio de TI reguladas, esas dos frases terminan la evaluación ahí mismo.

Con qué se está topando realmente la gente

La queja más sonora no es sobre herramientas ni créditos. Es que el token no deja de expirar. Un hilo de la comunidad de Atlassian titulado "The MCP Auth expires too fast" corre desde octubre de 2025 hasta marzo de 2026 con cerca de 16.500 visitas y sin resolución, y está lleno de usuarios de Claude Code:

"Bump! I need to reauthenticate sometimes once an hour, sometimes once every 10-20 minutes. This morning I authenticated the MCP connection then sent my prompt, 12 minutes later claude code was getting a 401 response and I only had a single terminal session open. This is basically unusable, I guess I'll just need to build some custom tools to utilize the API."

Aaron Kirn, Atlassian Community

Un Community Champion en el mismo hilo señaló la causa con claridad: el servidor emite tokens de OAuth de corta duración, los clientes externos no pueden renovarlos automáticamente, y los tokens de larga duración aún no se han lanzado. De ahí se derivan dos cosas si estás operando agentes en lugar de solo chatear.

Las sesiones en paralelo se pelean entre sí. Varias personas reportan que autenticarse en una ventana desautentica en silencio a las demás, lo que hace doloroso cualquier flujo de trabajo multiagente. Y el endpoint más nuevo /mcp falla de forma más silenciosa que el antiguo: un usuario señaló que /sse al menos lanzaba un 401 que podías capturar, mientras que el reemplazo "simplemente falla en silencio". Si estás configurando reintentos, captura el resultado vacío, no solo el código de error.

La calidad de las herramientas tiene su propio hilo, y esta es la parte que no esperaba. Un PM de Atlassian que trabaja en el servidor MCP respondió en Reddit, de forma oficial:

"Tool quality - the problem you mention where the Jira create tool doesn't respect required fields is something we just need to fix. We've been moving quickly to release a broad range of tools, and now we need to go back and fix some of those pain points. Tool descriptions included. You'll see some improvements here soon Context bloat - we acknowledge this is a problem as well. There are many more tools we want to provide but the current design is already at it's limit."

u/atlassiadam, Atlassian PM, r/mcp

La ansiedad por los créditos es el otro gran tema, y se trata sobre todo de Rovo, no de MCP. Un usuario de Bitbucket reportó que una sola revisión de pull request se comió casi la mitad de su asignación mensual:

"Rovo had a look at the PR and made a few suggestions and in doing so appeared to use 965 of my 2000 credits with 760 being marked as 'Code review in Bitbucket', I'm not sure where the other 205 went?? Either I'm doing something amazingly wrong or that's not value for money at all."

Chris Mingay, Atlassian Community

Un gestor de producto de Atlassian respondió en ese hilo y coincidió en que la cuenta era pesada, lo cual es justo, e inusualmente franco. La misma preocupación aparece en Reddit, donde un usuario del plan Standard hizo la comparación en voz alta:

"advertised ($0.01 per credit after the initial 2000), copilot is a mere $10 for 300 claude 4.5 requests why is it so expensive? the free tier..."

Rovo Dev credits, r/RovoDev

Ese mismo usuario describió haber quemado tres cuartas partes de 2.000 créditos en un par de horas, en no más de 30 solicitudes.

Ese contexto es exactamente por qué el modelo de precios del servidor MCP se lee hoy como un alivio en lugar de una preocupación. También es por qué la nota de facturación de Teamwork Graph merece un recordatorio en el calendario. Gratis-con-tu-plan es un producto muy distinto de facturado-en-créditos, y Atlassian ya te ha dicho hacia dónde van dos de esas herramientas.

Cómo decidiría yo en realidad

Si tu objetivo es análisis, control de calidad, informes de incidentes, o hacer preguntas a través de Jira y Confluence en un solo lugar, instala el conector hoy. Es el mejor plugin de IA para Jira gratuito que he probado este año. Gratis, oficial, el modelo de permisos es sólido, y solo-lectura-en-la-práctica es una ventaja la primera vez que apuntas una IA a una mesa en producción. Lo más fuerte y gratuito de la categoría, y no disuadiría a nadie de usarlo.

Si tu objetivo es guardia, las cuatro herramientas JSM se ganan su lugar, y vale la pena tener la conversación con tu administrador sobre habilitar la autenticación por token de API. Confirmar y escalar alertas directamente desde una ventana de chat es un flujo de trabajo real.

Si tu objetivo es resolver solicitudes de nivel 1 para que tu equipo deje de responder la misma pregunta de VPN, el conector no es esa herramienta, y ninguna cantidad de prompting lo va a convertir en una. Lo que necesitas es algo que hable /rest/servicedeskapi/, conozca la diferencia entre una respuesta pública y una nota interna, respete la cola y la política de SLA que ya has configurado, maneje la escalada con limpieza, y se pueda probar contra solicitudes que ya sucedieron antes de encontrarse con una que aún no. Mi resumen de la mejor IA para ITSM cubre el campo si quieres comparar en serio.

eesel AI para Jira Service Management

Ese último trabajo es el que construimos nosotros. eesel se suma a tu mesa de servicio como un agente de IA real, no como un widget atornillado al costado. Lee solicitudes, redacta y envía respuestas, añade notas internas, actualiza campos de la solicitud, fija la prioridad y enruta a equipos, todo dentro de las reglas de asignación y las políticas de SLA que ya tienes.

Lo que más me importaría al evaluar esto en una mesa real es la simulación. Repites tus solicitudes pasadas antes de que nada se acerque a una real, obtienes porcentajes de cobertura desglosados por tema, cubres las brechas que revele la ejecución, y lanzas solo cuando el número es lo bastante bueno. Construimos eso porque hemos visto bots que suenan seguros dar respuestas equivocadas en las colas de otras personas, y una prueba en seco sobre tu propio historial es la única manera honesta de averiguarlo antes.

Para hacerte una idea de cómo se ve eso en una mesa de soporte interna: InDebted usa JSM para un equipo de TI de 5 a 10 personas que da soporte a cientos de empleados en cinco mercados. Su conocimiento llega desde Confluence y desde un bot de Slack:

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, IT Team, InDebted, eesel case study

Hoy están en 15% de los tickets entrantes de Jira desviados, con 55% como objetivo una vez que la base de conocimiento se complete. Una cifra real de una mesa real, no una cifra de demostración. Y la parte honesta es que empezó en 15%, no en 55%.

El precio es 0,40 $ por solicitud gestionada. Facturado por solicitud en lugar de por respuesta, así que un intercambio de quince mensajes sigue contando como un solo cargo. Para empezar hay 50 $ de uso gratuito sin tarjeta, lo que equivale a 125 solicitudes, con cada función desbloqueada.

Si tu mesa de servicio vive en algún lugar distinto de JSM, el mismo agente funciona en Zendesk y seis helpdesks más.

Usa el conector de Atlassian para pensar. Para responder, usa algo que hable la API de la mesa de servicio. Trabajos distintos, y la buena noticia es que en 2026 ya no tienes que elegir solo uno.