Claude para Jira Service Management: quatro ferramentas JSM, nenhuma para tickets

A Atlassian fez o que todo mundo ainda promete

Eu construo agentes de IA na eesel, o que na prática significa que leio especificações de ferramentas de outras pessoas para viver. A pergunta "posso apontar o Claude para o nosso helpdesk" foi, de longe, a mais comum na minha caixa de entrada este ano. A resposta costuma ser alguma variação de não.

Quando verifiquei o Claude para Zendesk, o que a Zendesk tinha lançado era um cliente MCP, não um servidor. O Freshdesk está atrás de um programa de acesso antecipado. A Gorgias nem tem uma listagem no marketplace para isso. A Help Scout lançou um servidor de verdade, e depois o deixou somente leitura de propósito.

A Atlassian simplesmente construiu. Na página do Rovo MCP há uma grade de clientes de IA, e o Claude é um dos quatro, ao lado de Cursor, VS Code e ChatGPT. O texto da página menciona isso diretamente: fique no fluxo, "seja para obter contexto da Atlassian dentro do Claude". Um fornecedor apontando os próprios clientes para o modelo de outra empresa, de propósito, na sua própria página de marketing.

O modelo de acesso também é incomumente generoso. O próprio FAQ da Atlassian diz "Todos os clientes Atlassian Cloud têm acesso". Seu plano só muda a taxa de transferência: sites Free recebem 500 chamadas por hora, Standard 1.000, e Premium ou Enterprise recebem 1.000 mais 20 por usuário, até um teto de 10.000. Também não é exigida nenhuma assinatura do Rovo, porque, como a Atlassian coloca, o servidor "não é um modelo de IA, é uma camada de integração".

Então este texto não é uma demolição. É o que eu gostaria que alguém tivesse me contado antes de eu passar uma tarde esperando uma central de serviços e recebendo, em vez disso, um rastreador de tarefas.

As quatro formas de conectar o Claude ao Jira Service Management

Existem quatro caminhos. Eles se organizam em torno de um eixo que importa mais do que todos os outros juntos: se a coisa consegue colocar palavras na frente da pessoa que abriu o chamado.

A forma desse gráfico é todo o argumento. O caminho instantâneo, oficial e gratuito é exatamente o que não consegue responder a um solicitante. A mesma troca que encontrei no Help Scout, embora a Atlassian chegue lá por um caminho diferente. A Help Scout deliberadamente lançou algo somente leitura. A Atlassian lançou escrita, e depois nunca a apontou para a central de serviços.

Caminho 1: o servidor oficial, do começo ao fim

O endpoint é uma única string:

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

Um aviso, antes de você copiar uma configuração antiga de algum lugar. A Atlassian eliminou o transporte SSE legado: após 30 de junho de 2026, https://mcp.atlassian.com/v1/sse não é mais suportado. Essa data já passou. Então, se você herdou uma configuração do post de blog de um colega lá da primavera, ela está morta, e o sintoma vai parecer mais uma falha de autenticação do que uma descontinuação.

Para o Claude Code é um único comando:

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

Depois /mcp para rodar o fluxo OAuth. No Claude Desktop o caminho é Settings, Extensions, Browse extensions, Plugins, buscar Atlassian. E no claude.ai, a listagem da Atlassian fica no diretório de conectores, descrita como leitura e escrita, construída pela Atlassian.

Um detalhe de implementação pega as pessoas de surpresa já na primeira chamada. Toda ferramenta quer um cloudId, e a forma de conseguir um é getAccessibleAtlassianResources, que a Atlassian descreve como uma primeira chamada obrigatória para qualquer ferramenta. Pule essa etapa, deixe o Claude disparar direto para searchJiraIssuesUsingJql, e o erro que volta parece um problema de permissão. Não é.

A outra coisa que vale a pena saber no primeiro dia: o Claude alcança seu servidor MCP a partir da infraestrutura da Anthropic, nunca do seu notebook. Isso vale até no Claude Desktop. Então, se o seu site Atlassian estiver atrás de uma lista de permissão de IP, as chamadas de ferramentas vão falhar enquanto a tela de consentimento OAuth continua aparecendo tranquilamente, o que talvez seja o modo de falha mais confuso que existe.

Caminho 2: as quatro ferramentas JSM, e a barreira de token na frente delas

Agora, a parte que me fez parar e ler a página duas vezes.

A Atlassian publica cerca de 46 ferramentas, distribuídas em 13 grupos de permissões. O Jira recebe 14. O Confluence recebe 12, o Bitbucket também 12, o Compass 10. O Jira Service Management recebe quatro:

Cada uma dessas ferramentas vive no lado de operações, a parte do JSM que descende do alerta de plantão. Nenhuma toca na central de serviços. Não existe nenhuma ferramenta publicada para solicitações, tipos de solicitação, filas, SLAs, aprovações, clientes do portal ou configuração do portal.

E há uma segunda barreira até mesmo na frente dessas quatro. A página de ferramentas suportadas da Atlassian afirma que as ferramentas JSM "só suportam autenticação por token de API" e "só estão disponíveis se a autenticação por token de API for habilitada pelo administrador da sua organização". Enquanto isso, o OAuth é o fluxo padrão, e o recomendado. O resultado prático para a maioria das pessoas, então: um login normal do Claude não mostra nenhuma das ferramentas JSM, e nada na interface explica o motivo.

O Compass, aliás, segue a regra oposta: só OAuth, sem token de API. O Bitbucket quer um token de API e um workspace vinculado. Três produtos, três regras de autenticação diferentes, tudo dentro de um único servidor.

O que você realmente consegue alcançar em uma central de serviços

Nada disso significa que o Claude é cego para seus tickets. Um projeto JSM é um projeto Jira por baixo, então as ferramentas genéricas do Jira funcionam nele. getVisibleJiraProjects, getJiraIssue, searchJiraIssuesUsingJql, getTransitionsForJiraIssue, transitionJiraIssue, editJiraIssue e addCommentToJiraIssue operam todas tranquilamente sobre itens de trabalho do JSM.

Essa distinção importa mais do que parece. A própria documentação da Atlassian é direta sobre o que um tipo de solicitação traz: "Se você criar um item de trabalho sem um tipo de solicitação, suas solicitações não terão acesso a todos os recursos do Jira Service Management." O Claude está olhando para a camada do Jira embaixo da central de serviços, não para a central de serviços. Onde seus agentes veem uma solicitação com um relógio de SLA, uma fila, um portal e um cliente anexado, o Claude vê um item de trabalho.

A versão mais afiada dessa lacuna são os comentários. Na API da central de serviços, a visibilidade para o cliente se resume a exatamente um booleano no corpo do comentário:

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

public: true é uma resposta que o solicitante vê no portal. public: false é uma nota interna, só para agentes. Sem endpoint separado, sem objeto de visibilidade, só a flag. E a ferramenta MCP addCommentToJiraIssue não tem um parâmetro equivalente na sua descrição publicada, o que significa que o Claude não tem como declarar se as palavras que escreve são destinadas ao solicitante. Em uma central de TI isso não é uma sutileza que falta. É a diferença entre um recado para o colega e um e-mail para um diretor.

Vale a pena saber, se você seguir o caminho da API mais adiante: o recurso de comentário da central de serviços só expõe GET e POST. Sem PUT, sem DELETE. Retirar um comentário significa descer para a API da plataforma Jira em /rest/api/3/issue/{id}/comment/{id}, com a permissão Editar comentários próprios ou Excluir comentários próprios. Planeje o desfazer antes de precisar dele.

Caminho 3: a API REST da central de serviços, se você mesmo construir

Se você quer o comportamento consciente de fila, de SLA e visível para o cliente, você escreve isso sozinho contra /rest/servicedeskapi/. Isso é um projeto de verdade, não um fim de semana, e três coisas vão moldar o design mais do que você espera.

Limites de taxa são três sistemas ao mesmo tempo, e a Atlassian diz que sua integração "precisa lidar com os três". Uma cota horária baseada em pontos, limites de burst por segundo, e depois limites de escrita por chamado em cima disso. O Global Pool padrão é de 65.000 pontos por hora compartilhados entre tenants; um pool por tenant vai de 65.000 no Free até 150.000 mais 30 por usuário no Enterprise, com teto de 500.000. Os padrões de burst ficam em 100 requisições por segundo em GET e POST, e 50 em PUT e DELETE. As escritas por chamado têm teto de 20 em dois segundos e 100 em trinta. E um endpoint é dramaticamente mais restrito que todos os outros: GET /servicedeskapi/servicedesk/{id}/customer é limitado a 5 requisições por segundo, e será o primeiro muro que você vai bater em qualquer backfill de clientes.

Falhas silenciosas de permissão. A Atlassian documenta que em GET /request/{id}/comment, "nenhum erro de permissão é fornecido se, por exemplo, o usuário não tiver acesso à central de serviços ou à solicitação; o método simplesmente retorna uma resposta vazia". Então um agente que não lê nenhum comentário, e conclui que não havia nenhum, acaba respondendo com total confiança à pergunta errada.

O acesso à base de conhecimento é só de busca. GET /rest/servicedeskapi/knowledgebase/article retorna artigos que correspondem a uma consulta, por central de serviços ou em todas elas, e query é obrigatório. Nada nesse namespace busca o corpo completo de um artigo, então fundamentar respostas na sua base de conhecimento significa uma segunda viagem até a API do Confluence. O lado bom: os dois endpoints de KB são isentos das regras de acesso de apps, ao contrário de qualquer endpoint de solicitação e comentário.

O que uma resposta do JSM realmente custa

É aqui que o limite de somente leitura fica financeiramente interessante. Tokens são baratos, e o que eles compram é limitado.

Uma resposta bem fundamentada chega a cerca de 12.000 tokens de entrada depois que você puxa o ticket, as transições e duas páginas do Confluence, mais cerca de 700 tokens de saída na volta. No Claude Sonnet 5 a US$ 2 e US$ 10 por milhão, isso dá cerca de 3,1 centavos. Mais perto de 1,3 centavo quando o cache de prompt está fazendo o trabalho dele, a US$ 0,20 por milhão em leituras cacheadas. No Claude Opus 5 a US$ 5 e US$ 25, a mesma resposta fica perto de 7,8 centavos.

Agora as comparações. O agente virtual da própria Atlassian inclui 1.000 conversas assistidas por mês, e depois cobra a partir de US$ 0,30 cada daí em diante, e uma conversa que é associada a uma intenção e depois escalada para um humano ainda é cobrada. Os créditos Rovo são um medidor totalmente separado: o Standard recebe 25 por usuário por mês, o Premium 70, o Enterprise 150. As ferramentas beta do Teamwork Graph no servidor MCP são gratuitas hoje, mas a Atlassian disse que "serão cobradas a um mínimo de 1 crédito Rovo por chamada" na disponibilidade geral, com aviso prévio de 90 dias.

Um alerta antes de você levar qualquer número por conversa ao pé da letra, de um gerente de TI que levou o assunto diretamente à equipe de produto:

"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 a pena checar isso contra qualquer ferramenta que você escolher, a nossa inclusive. Uma taxa de desvio que conta abandono como sucesso está medindo a coisa errada, e é o número que mais provavelmente vão citar de volta para você em uma reunião de renovação.

Coloque seus próprios números:

A leitura honesta desses três números: a coluna de tokens é a mais barata porque é a que compra menos. Sem pipeline de resposta, sem flag de visibilidade, sem roteamento de fila, sem consciência de SLA, e nenhuma forma de se testar antes de encontrar um solicitante de verdade. Comparar isso com um preço por solicitação é comparar um assistente de pesquisa com um agente. Útil. Não é o mesmo trabalho.

O lado do administrador, e por que ele vai dizer acesso negado

Quatro coisas separadas precisam ser todas verdadeiras antes que uma única chamada de ferramenta chegue ao destino. Cada uma delas falha de um jeito diferente.

1. O domínio de IA precisa estar permitido. A Atlassian fornece uma lista padrão de domínios parceiros de IA, incluindo Claude e ChatGPT. Admins podem permitir ou bloquear, mas a Atlassian é explícita: "Você não pode bloquear domínios individuais. Você só pode permitir ou bloquear a lista inteira de domínios." O que não deixa nenhuma forma de permitir o Claude e recusar tudo o mais.
2. O IP precisa passar na lista de permissão, e essa aqui é traiçoeira, porque "a tela de consentimento OAuth 2.1 ainda pode aparecer para usuários se conectando de IPs bloqueados, mas as chamadas de ferramenta vão falhar". A conexão parece bem-sucedida até o exato momento em que não faz nada.
3. O método de autenticação precisa estar permitido. A autenticação por token de API é um interruptor de toda a organização, e é esse interruptor que decide se as ferramentas JSM existem para você. O bloqueio de domínio, aliás, não se aplica a conexões por token de API.
4. A saída de rede precisa alcançar *.atlassian.net, já que o servidor renderiza widgets interativos do Jira e do Confluence dentro do cliente de IA via iframes.

Além de tudo isso, uma aba de Permissões agora deixa admins da organização permitir ou bloquear Leitura, Escrita e Busca de forma independente por aplicativo, e a Atlassian diz que isso "vai ter precedência sobre as configurações em Connected Apps". Também existe uma opção "Aplicar a adições futuras". Que, silenciosamente, significa que permissões adicionadas recentemente podem herdar uma permissão sem que ninguém as revise. Se você é a pessoa que aprova revisões de acesso, vale a pena dar uma olhada nessa opção.

Dois fatos de compliance para passar à sua equipe de segurança antes que ela pense em perguntar. O servidor não armazena nem faz cache de nenhum conteúdo do Jira ou do Confluence, e roda estritamente dentro das permissões do usuário conectado, o que é um padrão melhor do que a maioria dos conectores. Mas a Atlassian afirma que "atualmente não suporta os requisitos de FedRAMP ou HIPAA", e é somente Cloud, sem nenhum caminho de Data Center ou Server publicado. Para muitas centrais de serviços de TI reguladas, essas duas frases encerram a avaliação ali mesmo.

No que as pessoas estão realmente esbarrando

A reclamação mais alta não é sobre ferramentas ou créditos. É que o token não para de expirar. Um tópico da comunidade Atlassian intitulado "The MCP Auth expires too fast" corre de outubro de 2025 a março de 2026, com cerca de 16.500 visualizações e nenhuma solução, e está cheio de usuários do 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

Um Community Champion no mesmo tópico apontou a causa claramente: o servidor emite tokens OAuth de vida curta, clientes externos não conseguem renová-los automaticamente, e tokens de vida longa ainda não foram lançados. Duas coisas decorrem disso se você estiver rodando agentes em vez de apenas conversando.

Sessões paralelas brigam entre si. Várias pessoas relatam que autenticar em uma janela desautentica silenciosamente as outras, o que torna qualquer fluxo de trabalho multiagente doloroso. E o endpoint mais novo /mcp falha de forma mais silenciosa do que o antigo: um usuário observou que o /sse pelo menos lançava um 401 que dava para capturar, enquanto o substituto "simplesmente falha em silêncio". Se você está configurando retentativas, capture o resultado vazio, não só o código de erro.

A qualidade das ferramentas tem seu próprio tópico, e essa é a parte que eu não esperava. Um PM da Atlassian trabalhando no servidor MCP respondeu no Reddit, oficialmente:

"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

A ansiedade com créditos é o outro grande tema, e é principalmente sobre o Rovo, não sobre o MCP. Um usuário do Bitbucket relatou que uma única revisão de pull request consumiu quase metade de sua cota mensal:

"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

Um product manager da Atlassian respondeu nesse tópico e concordou que a conta era pesada, o que é justo, e incomumente franco. A mesma preocupação aparece no Reddit, onde um usuário do plano Standard fez a comparação em 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

Esse mesmo usuário descreveu ter queimado três quartos de 2.000 créditos em poucas horas, em não mais que 30 solicitações.

Esse contexto é exatamente o motivo pelo qual o modelo de preços do servidor MCP soa como um alívio hoje, e não como uma preocupação. Também é por isso que a nota de cobrança do Teamwork Graph merece um lembrete no calendário. Grátis-com-seu-plano é um produto bem diferente de cobrado-em-créditos, e a Atlassian já disse para qual direção duas dessas ferramentas estão indo.

Como eu de fato decidiria

Se o seu objetivo é análise, QA, relatos de incidentes, ou fazer perguntas em Jira e Confluence em um só lugar, instale o conector hoje. É o melhor plugin de IA para Jira gratuito que testei este ano. Grátis, oficial, o modelo de permissões é sólido, e somente-leitura-na-prática é um recurso na primeira vez que você aponta uma IA para uma central em produção. A coisa gratuita mais forte da categoria, e eu não desencorajaria ninguém.

Se o seu objetivo é plantão, as quatro ferramentas JSM se justificam, e vale a pena ter a conversa com seu admin sobre habilitar a autenticação por token de API. Confirmar e escalar alertas direto de uma janela de chat é um fluxo de trabalho real.

Se o seu objetivo é resolver solicitações de nível 1 para que sua equipe pare de responder à mesma pergunta sobre VPN, o conector não é essa ferramenta, e nenhuma quantidade de prompting vai transformá-lo em uma. O que você precisa é de algo que fale /rest/servicedeskapi/, saiba a diferença entre uma resposta pública e uma nota interna, respeite a fila e a política de SLA que você já configurou, lide com a escalada de forma limpa, e possa ser testado contra solicitações que já aconteceram antes de encontrar uma que ainda não aconteceu. Meu levantamento da melhor IA para ITSM cobre o campo se você quiser comparar direito.

eesel AI para Jira Service Management

Esse último trabalho é exatamente o que construímos. A eesel entra na sua central de serviços como um agente de IA de verdade, não como um widget parafusado na lateral. Ela lê solicitações, redige e envia respostas, adiciona notas internas, atualiza campos da solicitação, define prioridade e roteia para times, tudo dentro das regras de atribuição e das políticas de SLA que você já tem.

A parte com que eu mais me importaria, ao avaliar isso em uma central real, é a simulação. Você reproduz suas solicitações passadas antes de qualquer coisa chegar perto de uma real, recebe percentuais de cobertura detalhados por tema, preenche as lacunas que a execução revelar, e só lança quando o número estiver bom o suficiente. Construímos isso porque já vimos bots de tom confiante darem respostas erradas nas filas de outras pessoas, e um teste seco sobre o seu próprio histórico é a única forma honesta de descobrir isso antes.

Para ter uma ideia de como isso se parece em uma central de suporte interna: a InDebted roda o JSM para uma equipe de TI de 5 a 10 pessoas que dá suporte a centenas de funcionários em cinco mercados. O conhecimento deles vem do Confluence e de um bot do 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

Hoje eles estão em 15% dos tickets do Jira desviados, com 55% como meta assim que a base de conhecimento se completar. Um número real de uma central real, não um número de demonstração. E a parte honesta é que começou em 15%, não em 55%.

O preço é de US$ 0,40 por solicitação atendida. Cobrado por solicitação, não por resposta, então uma troca de quinze mensagens ainda conta como uma única cobrança. Para começar há US$ 50 de uso gratuito sem cartão, o que dá 125 solicitações, com todos os recursos desbloqueados.

Se a sua central de serviços vive em outro lugar além do JSM, o mesmo agente roda no Zendesk e em mais seis helpdesks.

Use o conector da Atlassian para pensar. Para responder, use algo que fale a API da central de serviços. Trabalhos diferentes, e a boa notícia é que em 2026 você não precisa mais escolher só um.