Atlassian MCP Server: Setup, Allowlist & Veilige Toegang

Wat de Atlassian MCP server is

De Atlassian MCP server is Atlassian’s Rovo MCP server: een extern Model Context Protocol-eindpunt dat Jira, Confluence en Compass beschikbaar stelt als tools die een AI-agent kan aanroepen. Deze bevindt zich op https://mcp.atlassian.com/v1/mcp en authenticeert via OAuth2.

Het omvat drie producten:

De documentatie beschrijft de mogelijkheden in termen van het zoeken van issues, het lezen van pagina's en het aanmaken van tickets, in plaats van specifieke tool-functies te noemen. De definitieve lijst is wat verschijnt op het tabblad Tools nadat je autorisatie hebt verleend, aangezien de gateway de live upstream-lijst weerspiegelt.

Omdat het een externe server is, hoef je lokaal niets uit te voeren — geen Docker-container, geen npx-proces per laptop. Je verwijst een MCP client naar een URL en authenticeert, wat de grote kracht is van externe MCP servers in het algemeen.

Wat agents er daadwerkelijk mee doen

De interessantste toepassingen combineren tools over meerdere producten heen:

• Sprint triage. Openstaande Jira-issues zoeken, bijna-duplicaten groeperen, de gekoppelde Confluence-specificatie van elke groep ophalen om te controleren of de vereiste is gewijzigd, en een geconsolideerd ticket aanmaken.
• Incidentverslaglegging. Het Jira-incident lezen, Confluence doorzoeken naar het runbook, de verantwoordelijke service ophalen uit Compass en een post-mortem opstellen met verwijzingen naar alle drie.
• Van spec naar ticket. Een Confluence-specificatie lezen, deze opbreken in Jira-tickets met acceptatiecriteria overgenomen van de pagina, en elk ticket terugkoppelen naar de bron.
• Eigenaarschap opzoeken. Er komt een vraag binnen over een service die niemand kent. De agent raadpleegt Compass voor het component en geeft vervolgens antwoord vanaf de Confluence-architectuurpagina.

De scheiding die er echt toe doet is niet alleen lezen versus schrijven — het is openbaar versus gevoelig. Het lezen van een Jira-issue is onschadelijk. Een ticket aanmaken is te herstellen. Het lezen van Confluence vereist de meeste aandacht: het is de plek waar bedrijven bestuursdocumenten, salarisschalen, post-mortems met persoonsnamen en beveiligingsarchitectuur bewaren. Een read-only agent met onbeperkte Confluence-toegang heeft een grotere impact bij misbruik dan een schrijfbevoegde agent die beperkt is tot één Jira-project.

Die asymmetrie is specifiek voor Atlassian, en dat is waarom "schrijf-tools uitschakelen" hier een onvolledig advies is.

Waarom een directe koppeling op teamschaal misgaat

Wanneer één engineer dit in Cursor instelt, is er niets aan de hand. Dertig engineers plus een support-agent en een documentatie-agent is een heel ander verhaal.

De allowlist is een beslissing voor de gehele organisatie. Dit wordt per organisatie ingesteld, niet per team. Degene die de rol van org-admin heeft in admin.atlassian.com bepaalt of deze integratie überhaupt bestaat. Als je tooling ad-hoc koppelt, verzamel je toegestane domeinen die niemand meer controleert.

Geen audit trail van de intentie. Atlassian registreert dat er een API-call is uitgevoerd op het account van een gebruiker. Het registreert niet dat jouw triage-agent deze uitvoerde op basis van een prompt uit een Slack-thread. Wanneer er een ticket verschijnt waarvan niemand zich herinnert het te hebben ingediend, is er geen keten te reconstrueren.

Leesbereik op Confluence is "alles wat de gebruiker kan zien." Rechten per gebruiker is de juiste opzet, maar de meeste omgevingen hebben door historische redenen ruim ingestelde Confluence-spacerechten. Wat een gebruiker kan zien is meestal veel meer dan wat een taak vereist, en de agent kan dat onderscheid niet maken.

Prompt injection heeft een doelwit. Jira-beschrijvingen en Confluence-pagina's zijn teksten die een agent leest en die door iemand anders geschreven kunnen zijn. Een issue ingediend door een externe melder via een service desk-portal, met daarin instructies, gelezen tijdens een triage waarbij Confluence-toegang actief is in dezelfde sessie — dat is een directe route van niet-vertrouwde invoer naar gevoelige uitvoer. De fout is niet dat de agent zich verkeerd gedroeg; het is dat de rechten breder waren dan de taak.

Dit zijn geen redenen om de server te vermijden. Het zijn redenen om er een control plane voor te plaatsen — en dat is precies waar een MCP gateway voor bedoeld is.

Probeer het zelf.

Maak een TrueFoundry-account aan, zet je domein één keer op de allowlist in Atlassian en geef je team beheerde toegang tot Jira en Confluence.

Gratis aan de slag

Stap 0: TrueFoundry op de allowlist zetten in Atlassian

Dit is de stap die teams vaak blokkeert, dus deze behandelen we eerst. Het is een vereiste aan de kant van Atlassian en geen enkele TrueFoundry-instelling kan dit vervangen.

Je hebt nodig: rechten om MCP servers toe te voegen in TrueFoundry, een Atlassian Cloud-organisatie met Jira, Confluence of Compass, en organization admin-toegang in admin.atlassian.com.

Selecteer in Atlassian Admin je organisatie en open Apps → AI settings → Rovo MCP server. Voeg onder Allowed domains het domein van je TrueFoundry control plane toe:

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

Er hoeft geen OAuth client aangemaakt te worden. Atlassian regelt de dynamische clientregistratie voor domeinen op de allowlist. Voor de meeste zelf-geregistreerde externe MCP servers maak je een OAuth-app aan in de portal van de provider, stel je een redirect URI in en sla je een client ID en secret op. Hier hoeft dat niet — de allowlist-regel is de vertrouwensrelatie.

De allowlist is je noodknop (kill switch). Het verwijderen van het domein trekt nieuwe OAuth-verbindingen direct in. Het stopzetten van deze integratie voor de gehele organisatie is één enkele wijziging in Atlassian Admin, los van de gateway. Weinig integraties bieden zo'n duidelijke controle; noteer goed waar deze optie te vinden is.

Een belangrijk netwerkpunt: als Atlassian IP allowlisting is ingeschakeld, moet je ook het verkeer toestaan vanaf de omgeving van waaruit TrueFoundry verbinding maakt met de externe MCP server.

De Atlassian MCP server verbinden via TrueFoundry

Stap 1 — Open de keuzelijst. Ga in TrueFoundry naar MCP Gateway, klik op Add MCP Server en selecteer Atlassian.

Dit is niet de TrueFoundry Managed MCP-catalogusflow, waarbij je alleen een naam opgeeft en het platform elk veld beheert. Atlassian vereist expliciete waarden, omdat de vertrouwensrelatie voortkomt uit de allowlist en niet uit door het platform beheerde authenticatiegegevens.

Stap 2 — Configureer de server. Gebruik de volgende waarden:

Schakel Auth Data in en selecteer het tabblad OAuth2. Omdat je domein op de allowlist staat, heb je geen client ID of secret nodig — laat deze leeg.

Stap 3 — Voeg collaborators toe. Voeg de gebruikers of teams toe die Atlassian-tools mogen gebruiken. Wijs MCP Server Manager toe aan beheerders en MCP Server User aan eindgebruikers.

Stap 4 — Opslaan en autoriseren. Klik op Add MCP Server. Elke gebruiker opent vervolgens de sectie Tools van de server en klikt op Connect Now om de Atlassian OAuth te voltooien. De tools verschijnen daarna en kunnen getest worden in de Agent Playground.

Hoe authenticatie daadwerkelijk werkt

TrueFoundry maakt onderscheid tussen inkomende (inbound) authenticatie — hoe een client zich bewijst tegenover de gateway — en uitgaande (outbound) authenticatie, hoe de gateway zich bewijst tegenover Atlassian. Deze lagen staan los van elkaar.

Inkomend (Inbound) — vier ondersteunde methoden:

Eén belangrijk aandachtspunt hier: Virtual Account-tokens geven elk verzoek identieke toegang. Ze kunnen daarom geen individuele Atlassian-rechten per gebruiker toepassen — ze brengen je gehele rechtenmodel terug tot wat die ene identiteit kan bereiken. Gebruik inkomend een PAT of IdP-token.

Uitgaand (Outbound) — voor Atlassian is dit OAuth2. Elke gebruiker autoriseert hun eigen account via Connect Now, en TrueFoundry beheert de toestemming, tokenopslag en verversing. Tokens worden per gebruiker bij elke call geïnjecteerd. TrueFoundry ontvangt nooit Atlassian-inloggegevens.

Het praktische effect, zoals duidelijk vermeld in de documentatie: elke gebruiker werkt met hun bestaande Jira-, Confluence- en Compass-rechten. Geen enkel gedeeld service-account heeft tenant-brede Confluence-leesrechten, en wanneer iemands Atlassian-toegang wordt ingetrokken, vervalt direct de toegang van hun agent.

Gebruikers authenticeeren zich twee keer — eerst bij de gateway, daarna bij Atlassian. Dat is wat toewijzing per gebruiker mogelijk maakt.

Tools afkaderen voordat je live gaat

Het tabblad Tools toont alles wat de server beschikbaar stelt.

Schakelaars per tool. Schakel een tool uit en deze wordt volledig weggelaten uit tools/list — clients zien de tool nooit en deze kan niet worden aangeroepen. Dit is geen filtering op prompt-niveau. Wijzigingen worden direct opgeslagen met een Tool settings updated melding.

Voor Atlassian is de meest waardevolle actie meestal niet "alle schrijf-tools uitschakelen". Het is het uitschakelen van Confluence-tools voor agents die alleen in Jira werken. Een sprint-triage-agent heeft Jira-zoekfuncties en leesrechten voor issues nodig, niet de mogelijkheid om elke Confluence-space in de tenant te doorzoeken — en een tool die de agent niet kan aanroepen, is een tool die niet misbruikt kan worden via een kwaadaardige issue-beschrijving.

Enable new tools by default. Dit bepaalt wat er gebeurt als Atlassian een nieuwe tool uitbrengt. Laat je dit aan staan, dan verschijnen nieuwe tools automatisch en groeit je functionaliteit vanzelf. Zet je het uit, dan zijn alleen tools beschikbaar die je expliciet hebt ingeschakeld. Voor een server die drie producten beslaat met verschillende gevoeligheidsprofielen, is uitschakelen veiliger.

Bulk Action. Verandert elke rij in selectievakjes met een Select all-optie, om snel een gecureerde allowlist op te stellen.

Klik op het potlood bij een tool om aan te passen hoe deze aan het model wordt gepresenteerd:

De Description override (tot 20.000 tekens) stuurt de toolselectie wanneer de upstream-formulering onduidelijk is — erg nuttig voor Jira en Confluence, waar "zoeken" twee verschillende dingen kan betekenen. MCP Tool Annotations markeren een tool als Read-only of Destructive (door het instellen van readOnlyHint of destructiveHint). Het correct annoteren zorgt ervoor dat het onderstaande goedkeuringsbeleid een hele categorie tools kan afschermen zonder ze een voor een te hoeven benoemen.

Wie wat mag doen: collaborator-rollen

Toegangsbeheer wordt gekoppeld aan gebruikers, teams of virtual accounts, op twee niveaus: welke servers een identiteit kan bereiken, en welke tools deze kan aanroepen.

Menselijke goedkeuring voor destructieve tools

Het uitschakelen van tools is een rigoureuze maatregel. Soms wil je dat een agent een Jira-ticket aanmaakt — maar niet onbeheerd. Dat is waar tool-goedkeuringsbeleid (approval policies) voor dient.

Wanneer een beveiligde tool wordt aangeroepen, wordt de call ingehouden in plaats van uitgevoerd. Er wordt een verzoek aangemaakt in de status 'in behandeling' (pending) en de approvers worden op de hoogte gesteld. Herhaalde calls van dezelfde aanvrager hergebruiken dat verzoek. Eenmaal goedgekeurd, slagen de calls gedurende een instelbare tijdsduur.

Maak een policy aan onder AI Gateway → Policies → MCP Tool Approval (gemarkeerd als Beta in de console):

Elke policy geeft aan welke servers deze beveiligt en kiest een approval scope:

Markeer de Atlassian-tools die kunnen schrijven één keer als Destructive en beveilig de hele categorie met approval_scope: destructive. Bij overlappende scopes wint de meest specifieke: named > destructive > all.

Validity is Once (eenmalige uitvoering) of op tijdsbasis. Bij conflicterend beleid wint de meest strikte regel — Once wint van een venster van 10 minuten, wat weer wint van een venster van 30 minuten.

Goedkeurders (approvers) ontvangen een melding via e-mail, Slack, PagerDuty of MS Teams en beoordelen het verzoek in de console:

Elk verzoek toont de tool, het beleid, de aanvrager, approvers, geldigheidstermijn en de daadwerkelijke argumenten van de tool — zo kan een approver de inhoud van het ticket lezen voordat de agent het definitief indient. Zolang het verzoek in behandeling is, ontvangt de aanroeper een JSON-RPC resultaat met _meta.approval_status: "pending" in plaats van een foutmelding, zodat een goed geprogrammeerde agent wacht en het opnieuw probeert in plaats van vast te lopen.

Toestemmingen worden verleend per aanvrager; goedkeuring voor één engineer geldt dus niet voor het hele team, en een afwijzing blokkeert niet permanent — de volgende call maakt een nieuw verzoek aan. Let ook op de waarschuwing in de documentatie: als een server in een policy geen MCP Server Approver collaborators heeft ingesteld, kunnen alleen tenant admins de verzoeken goedkeuren.

Testen in de playground

Voordat je een agent koppelt, is het verstandig de tools handmatig te testen. Klik op Try naast een willekeurige tool, vul de parameters in en bekijk de respons. Try is uitgeschakeld voor tools die je hebt uitgezet. Geautoriseerde tools kunnen ook worden uitgetest vanuit de Agent Playground.

Hiermee spoor je eenvoudige problemen vroegtijdig op — zoals een Confluence-space die de gebruiker niet kan zien, of een onjuiste Jira-projectcode. Dit is ook de plek waar netwerkproblemen met IP-allowlisting aan het licht komen: de OAuth-koppeling slaagt, de tools worden opgelijst, maar elke call mislukt.

Gebruik vanuit je IDE

Open het tabblad How To Use voor je tenant-specifieke Gateway URL en kant-en-klare codefragmenten.

How To Use tabblad met codefragmenten voor Python, TypeScript, Cursor, VS Code, Claude Code en Windsurf, inclusief de knoppen Add MCP to Cursor en Show API Key

Het biedt ondersteuning voor Claude Code, VS Code, Claude Desktop, Cursor, Windsurf en de Python- en TypeScript MCP SDK's. Add MCP to Cursor schrijft de configuratie direct weg; Show API Key toont de token als je client deze in een header vereist. Als er geen sleutel verschijnt, ondersteunt je platformversie de OAuth-flow en wikkelt Cursor dit automatisch af.

Kopieer de URL direct van dit tabblad in plaats van deze handmatig samen te stellen — een handmatig gebouwd eindpunt is de meest voorkomende oorzaak van een client die wel verbindt maar geen tools toont.

Wat het oplevert achter de gateway

Metrics op tool-niveau. Het MCP Metrics-dashboard geeft inzicht in requests per seconde, latency (P50/P75/P90/P99), foutpercentages per type en het aantal verzoeken per tool.

Zo ontdek je bijvoorbeeld dat een triage-agent veertig Confluence-zoekopdrachten uitvoert per ticket. Een MCP Method Calls Breakdown splitst het verschil tussen tools/list en tools/call.

Volledige observability van verzoeken. Elke call wordt getracet met identiteit van de aanroeper, toolnaam, invoerwaarden en latency, en kan via OpenTelemetry geëxporteerd worden naar Grafana, Datadog of Prometheus. Voor een integratie die interne documenten leest, is "welke agent van welke gebruiker heeft welke pagina gelezen, op basis van welke prompt" precies de audit trail die je nodig hebt.

Guardrails. Guardrails voor en na de tool-call voeren beleid uit op MCP tool-calls — zo wordt bijvoorbeeld voorkomen dat een inloggegeven op een Confluence-pagina naar het model wordt gestuurd.

Lage overhead. De gateway voegt slechts ongeveer 3–4 ms latency toe en kan 350+ RPS verwerken op een enkele vCPU.

Eén centrale registry. Als er meerdere servers zijn geregistreerd, kun je een gecureerde subset van tools bundelen achter één eindpunt met een Virtual MCP Server — zo krijgt een incident-agent exact de Jira-, Compass- en Slack-tools die nodig zijn.

Toegang intrekken

Er zijn twee onafhankelijke manieren om toegang in te trekken.

Bij Atlassian: verwijder het TrueFoundry-domein uit Allowed domains. Dit trekt nieuwe OAuth-verbindingen organisatiebreed in, los van de gateway.

Bij de gateway: tenant admins kunnen alle opgeslagen inloggegevens wissen via het driepuntenmenu naast Edit.

Revoke all tokens verwijdert alle ingestelde autorisaties en opgeslagen OAuth-tokens voor alle gebruikers en virtual accounts op die server. Dit wordt direct van kracht bij het volgende verzoek en wordt vastgelegd in de Activity Logs. Deze actie kan niet ongedaan worden gemaakt — iedereen moet opnieuw toestemming geven. Alleen tenant admins zien deze optie.

Een belangrijk detail: dit wist alleen de tokens bij de gateway, niet de verleende toestemmingen binnen Atlassian zelf. Voer bij een echt beveiligingsincident beide acties uit.

Aandachtspunten om te weten

De allowlist blokkeert voordat iets anders dat doet. Als Connect Now mislukt met een generieke OAuth-foutmelding, controleer dan eerst Apps → AI settings → Rovo MCP server → Allowed domains. Geen enkele aanpassing aan de gateway-zijde kan dit oplossen.

Lege OAuth client-velden horen zo. Omdat Atlassian dynamische clientregistratie gebruikt voor domeinen op de allowlist, is er geen client ID of secret. Teams die gewend zijn aan de standaard remote-MCP flow — een OAuth-app aanmaken, de callback instellen op https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback, inloggegevens plakken — gaan vaak naar die stap op zoek. Die stap is er niet.

IP-allowlisting uit zich anders. Als Atlassian IP allowlisting aan staat en het uitgaande verkeer van TrueFoundry niet is toegestaan, slaagt de OAuth-koppeling wel, maar mislukken de tool-calls. De symptomen lijken op een authenticatiefout, maar de oplossing ligt in het netwerk.

Gerelateerde artikelen

• What Is an MCP Gateway: Architecture and Use Cases — de architectonische basis achter dit artikel
• MCP Access Control: Securing AI Agents with an MCP Gateway — hoe rechten op tool- en serverniveau werken
• MCP Authentication Explained — inkomende versus uitgaande authenticatie in detail
• Virtual MCP Server Explained — het bundelen van tools uit verschillende servers naar één eindpunt
• MCP Server Security Best Practices — de bredere hardening-checklist

Conclusie

De Atlassian MCP-server is ongebruikelijk in die zin dat de moeilijkste afhankelijkheid administratief is, niet technisch. Je kunt geen verbinding maken totdat een org-admin jouw domein op de allowlist zet — en diezelfde allowlist is de schoonste uit-knop die deze integraties bieden. Teams die dit als een obstakel behandelen, lopen vast bij de installatie; teams die dit als een beheermaatregel behandelen, leggen vast wie de eigenaar is en gaan verder.

Het tweede punt dat goed moet staan is scope, en hier verschilt Atlassian van een code-host. Confluence bevat de teksten die bedrijven het liefst *niet* laten parafraseren in een chatvenster door een agent die alleen bedoeld was om tickets aan te maken. OAuth per gebruiker geeft je de ondergrens van rechten; het uitschakelen van tools die een agent helemaal niet hoort aan te roepen geeft je het plafond.

Verbind de Atlassian MCP-server op TrueFoundry

Gratis te starten