Servidor MCP da Atlassian: Configuração, Lista de Permissões e Acesso Seguro

O que é o servidor MCP da Atlassian

OServidor MCP da Atlassian é o servidor MCP do Atlassian Rovo: um Model Context Protocol remoto que expõe o Jira, o Confluence e o Compass como ferramentas que um agente de IA pode chamar. Ele está hospedado em https://mcp.atlassian.com/v1/mcp e autentica via OAuth2.

Ele abrange três produtos:

A documentação descreve a interface em termos de busca de tarefas, leitura de páginas e criação de chamados, em vez de nomear as funções das ferramentas. A lista oficial é o que quer que apareça na aba Ferramentas após a autorização, já que o gateway reflete a lista atualizada em tempo real.

Como ele é remoto, não há nada para executar localmente — sem contêiner Docker, sem processo npx por laptop. Você aponta um cliente MCP para uma URL e autentica, o que é o grande atrativo dos servidores MCP remotos em geral.

O que os agentes realmente fazem com ele

Os usos interessantes encadeiam ferramentas entre produtos:

• Triagem de sprint. Pesquise tarefas abertas no Jira, agrupe duplicatas próximas, extraia a especificação vinculada no Confluence de cada grupo para verificar se o requisito mudou e crie um chamado consolidado.
• Relatório de incidente. Leia o incidente no Jira, pesquise o runbook no Confluence, extraia o serviço responsável do Compass e redija um post-mortem citando os três.
• De especificação para ticket. Leia uma especificação no Confluence, divida-a em tickets do Jira com critérios de aceite extraídos da página e vincule cada um à fonte original.
• Consulta de propriedade. Uma pergunta surge sobre um serviço que ninguém conhece. O agente consulta o Compass para identificar o componente e, em seguida, responde com base na página de arquitetura do Confluence.

A divisão que realmente importa não é apenas entre leitura e escrita — é entre público e sensível. Ler um issue do Jira é inofensivo. Criar um é algo reversível. Ler o Confluence exige muito mais cautela: é onde as empresas armazenam apresentações de diretoria, faixas salariais, post-mortems com nomes de funcionários e arquitetura de segurança. Um agente com permissão apenas de leitura e acesso irrestrito ao Confluence tem um raio de impacto muito maior do que um agente com permissão de escrita limitado a um único projeto no Jira.

Essa assimetria é específica da Atlassian, e é por isso que "desativar as ferramentas de escrita" é um conselho incompleto neste caso.

Por que a conexão direta falha em escala de equipe

Um engenheiro configurando isso no Cursor é aceitável. Trinta engenheiros, mais um agente de suporte e um agente de documentação, é um problema diferente.

A lista de permissões é uma decisão de toda a organização. Ela é definida por organização, não por equipe. Quem possui privilégios de administrador da organização em admin.atlassian.com decide se essa integração existirá ou não. Conectar ferramentas de forma improvisada faz com que você acumule domínios permitidos que ninguém revisa.

Sem trilha de auditoria de intenção. A Atlassian registra que uma chamada de API foi feita na conta de um usuário. Ela não registra que seu agente de triagem a fez enquanto processava um prompt de uma thread do Slack. Quando um ticket aparece e ninguém se lembra de tê-lo criado, não há como reconstruir o histórico.

O escopo de leitura do Confluence é "tudo o que o usuário pode ver". Permissões por usuário são o design correto, mas a maioria dos ambientes possui permissões de espaço no Confluence permissivas por razões históricas. O que um usuário pode ver geralmente é muito mais do que o necessário para uma tarefa, e o agente não consegue distinguir essa diferença.

A injeção de prompt tem onde se instalar. Descrições do Jira e páginas do Confluence são textos que um agente lê e que podem ter sido escritos por outra pessoa. Um issue aberto por um relator externo através de um portal de service desk, contendo instruções, lido durante a triagem com acesso ao Confluence ativo na mesma sessão — esse é um caminho que vai de uma entrada não confiável a uma saída sensível. A falha não é que o agente se comportou mal; é que suas permissões eram mais amplas do que sua tarefa exigia.

Nenhum desses são motivos para evitar o servidor. São motivos para colocar um plano de controle na frente dele — que é para o que o gateway de MCP is for.

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

serve.

Passo 0: incluir o TrueFoundry na lista de permissões (allowlist) da Atlassian

Este é o passo que bloqueia as equipes, por isso vem primeiro. É um pré-requisito do lado da Atlassian e nenhuma configuração do TrueFoundry o substitui. Você precisa de: permissão para adicionar servidores MCP no TrueFoundry, uma organização Atlassian Cloud com Jira, Confluence ou Compass, e acesso de administrador da organização em.

admin.atlassian.com No Atlassian Admin, selecione sua organização e abraApps → AI settings → Rovo MCP server . EmAllowed domains

, adicione o domínio do seu plano de controle TrueFoundry:

https://<tfy-control-plane-base-url>/** Não há cliente OAuth para criar. é A Atlassian gerencia o registro dinâmico de clientes para domínios na lista de permissões. Para a maioria dos servidores MCP remotos autorregistrados, você criaria um aplicativo OAuth no portal do provedor, definiria um URI de redirecionamento e armazenaria um ID de cliente e um segredo. Aqui você não faz isso — a entrada na lista de permissões

estabelece a relação de confiança. A lista de permissões é o seu botão de emergência.

Remover o domínio revoga novas conexões OAuth. Interromper essa integração em toda a organização é uma única alteração no Atlassian Admin, independente do gateway. Poucas integrações oferecem um controle tão limpo; anote onde ele fica. Lista de permissão de IP da Atlassian estiver ativada, permita também o tráfego do ambiente onde o TrueFoundry se conecta ao servidor MCP remoto.

Conectando o servidor MCP da Atlassian através do TrueFoundry

Passo 1 — Abra o seletor. No TrueFoundry, abra MCP Gateway, clique em Adicionar Servidor MCPe selecione Atlassian.

Seletor de Adicionar Servidor MCP mostrando os caminhos de registro disponíveis, incluindo servidores remotos oficiais, qualquer servidor MCP remoto, MCPs gerenciados pelo TrueFoundry, STDIO hospedado e Importar de especificação OpenAPI

Este é não o fluxo do catálogo de MCP gerenciado pelo TrueFoundry, onde você fornece apenas um nome e a plataforma cuida de todos os campos. O Atlassian requer valores explícitos, pois a relação de confiança veio da lista de permissões em vez de credenciais mantidas pela plataforma.

Passo 2 — Configure o servidor. Use estes valores:

Campo

Valor

Nome

atlassian

Descrição

Atlassian é uma plataforma de desenvolvimento de software

URL

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

Autenticação

OAuth2

Ative Dados de autenticação e selecione a aba OAuth2 . Como seu domínio está na lista de permissões, você não precisa de um ID de cliente ou segredo — deixe-os em branco.

Passo 3 — Adicione colaboradores. Adicione os usuários ou equipes que devem usar as ferramentas da Atlassian. Atribua o MCP Server Manager aos administradores e Usuário do Servidor MCP para consumidores.

Passo 4 — Salvar e autorizar. Clique em Adicionar Servidor MCP. Cada usuário então abre a seção Ferramentas do servidor e clica em Conectar Agora para concluir o OAuth da Atlassian. As ferramentas aparecerão e poderão ser testadas a partir do Playground de Agentes.

Painel de Servidores MCP mostrando um servidor não autorizado no estado “Você não está conectado a este Servidor MCP” com um botão Conectar Agora

Como a autenticação realmente funciona

O TrueFoundry separa a autenticação de entrada — como um cliente se autentica no gateway — da autenticação de saída, como o gateway se autentica na Atlassian. As camadas são independentes.

Fluxo de autenticação e autorização do Gateway MCP mostrando a autenticação de entrada, controle de acesso e autenticação de saída como três estágios distintos

Entrada — quatro métodos suportados:

‍