Atlassian Rovo MCP Server einrichten

Der Atlassian Rovo MCP Server ist gehostet: Es wird nichts lokal installiert, der MCP-Client verbindet sich direkt mit mcp.atlassian.com. Aktuell empfiehlt Atlassian ausschließlich Version 2 unter https://mcp.atlassian.com/v2/mcp.

In Claude Code einrichten

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

Danach in einer Session /mcp ausführen, um die OAuth-Anmeldung zu starten. Nach der Bestätigung im Browser stehen die Atlassian-Werkzeuge bereit.

In Codex einrichten

codex mcp add atlassian --url https://mcp.atlassian.com/v2/mcp

In anderen Clients einrichten

Für Cursor, VS Code mit GitHub Copilot, ChatGPT, Gemini CLI und Windsurf bietet das offizielle Repository fertige Installationslinks bzw. Marktplatz-Einträge. Clients ohne native Remote-Unterstützung binden den Server über das npm-Paket mcp-remote und die Server-URL https://mcp.atlassian.com/v2/mcp ein.

Authentifizierung ohne interaktiven Login

Für Automationen ohne Browser-Zugriff lässt sich statt OAuth ein persönliches API-Token (Basic-Auth) oder ein Service-Account-API-Key (Bearer-Token) verwenden. Beides muss ein Organisationsadministrator zunächst unter Atlassian Administration → Rovo → Rovo MCP Server → Authentication freischalten. Für Jira-Service-Management-Werkzeuge ist API-Token-Authentifizierung ohnehin die einzige unterstützte Variante.

Zugriff eng halten

Der Werkzeugkatalog ist in Berechtigungsgruppen je Produkt gegliedert (Lesen, Schreiben, Suchen, Löschen, Verwalten). Organisationsadministratoren sollten neu angebundenen Clients zunächst nur Lesezugriff geben und Schreib-, Lösch- oder Verwaltungsrechte erst freischalten, wenn der Agent zuverlässig arbeitet. Alle Aktionen bleiben ohnehin auf das begrenzt, was das angemeldete Konto in Atlassian Cloud bereits sehen und tun darf.

Umstieg von v1 auf v2

Bestehende v1-Verbindungen wechseln laut Atlassian automatisch auf die v2-Werkzeuge. Der alte SSE-Endpunkt https://mcp.atlassian.com/v1/sse wird ab dem 30. Juni 2026 abgeschaltet; wer noch einen Client darauf konfiguriert hat, sollte rechtzeitig auf /v2/mcp umstellen und gegebenenfalls zwischengespeicherte Client-IDs oder .well-known-Zugangsdaten löschen, falls die Authentifizierung danach fehlschlägt.

Berechtigungsgruppen im Detail verstehen

Da der Werkzeugkatalog produktweise in eigene Berechtigungsgruppen unterteilt ist, lohnt sich vor der Freigabe ein Blick auf die konkrete Zuordnung: Ein Werkzeug zum Erstellen von Confluence-Seiten fällt in eine andere Gruppe als eines zum Löschen von Jira-Tickets, obwohl beide auf denselben Atlassian-Arbeitsbereich zugreifen. Organisationsadministratoren sollten diese Gruppen produktspezifisch statt pauschal freigeben.

Einrichtung prüfen

Nach der OAuth-Bestätigung mit einer harmlosen, rein lesenden Aufgabe testen, etwa „Zeig mir die letzten Jira-Tickets in Projekt X" oder „Suche in Confluence nach Onboarding-Dokumenten". Erst wenn das zuverlässig funktioniert, weitere Berechtigungsgruppen freischalten.

Diese schrittweise Freigabe kostet zwar etwas Zeit bei der Einrichtung, verhindert aber, dass ein noch nicht ausreichend getesteter Agent versehentlich weitreichende Änderungen an produktiven Jira- oder Confluence-Daten vornimmt.

Quelle: github.com/atlassian/atlassian-mcp-server und support.atlassian.com/atlassian-rovo-mcp-server, geprüft am 06.09.2026.