Rund um Atlassian, Rovo und den Teamwork Graph ist ein kleines Begriffs-Chaos entstanden: CLI, MCP, API – alles klingt nach Zugriff auf Kontext, aber nicht alles meint dasselbe. Wer Atlassian Cloud im Alltag nutzt, fragt sich daher schnell: Muss ich das verstehen, installieren oder aktiv nutzen? Dieser Blogpost bringt Struktur in die Begriffe und gibt eine Orientierung, welcher Ansatz für welchen Anwendungsfall sinnvoll ist.
Was ist der Teamwork Graph?
Die Qualität der Antworten und Aktionen eines LLMs oder KI-Agenten hängt maßgeblich vom verfügbaren Kontext ab. Der Teamwork Graph soll diesen Kontext nutzbar machen, indem er inhaltliche und strukturelle Zusammenhänge innerhalb einer Organisation als Wissensgraph abbildet und Agenten zugänglich macht.
Konkret verbindet der Teamwork Graph (twg) Personen, Ziele, Code und Inhalte über Atlassian Produkte und über Rovo-Konnektoren angebundene Drittanbieter Tools hinweg. So können beispielsweise auch Informationen aus Slack, Google Drive oder GitHub in den gemeinsamen Kontext einfließen. Dieser Ansatz orientiert sich an GraphRAG (Graph-based Retrieval-Augmented Generation). Einen technischen Deep Dive in die Funktionsweise von diesem haben wir in unserem Blog-Beitrag zu Diagnostic Graph RAG zusammengefasst. Wer eine Atlassian Cloud Instanz nutzt, kann den Teamwork Graph der eigenen Organisation unter Atlassian Teamwork Graph visualisieren.
Wie können aber Agenten, Skripte und Automatisierungen auf den Atlassian Teamwork Graph zugreifen? Dafür stehen derzeit vor allem zwei offiziell nutzbare Wege im Vordergrund: das Teamwork Graph CLI und der Rovo MCP Server. Welcher Ansatz sinnvoll ist, hängt vor allem davon ab, ob der Agent in einer Shell-Umgebung oder in einem MCP-fähigen Host, etwa einer IDE oder einem Web Chat, läuft.
CLI vs. MCP vs. API: Die Unterschiede auf einen Blick
vgl. Atlassian Support
Das Teamwork Graph CLI – die Lösung für Entwickler und Automatisierungen
Mit dem CLI (Command Line Interface) stellt Atlassian eine Schnittstelle bereit, über die Agenten direkt im Terminal auf den Graphen zugreifen können. Befehle wie twg work query können beispielsweise genutzt werden, um arbeitsbezogene Informationen aus dem Graphen abzurufen.
Das Teamwork Graph CLI deckt mit seinen Befehlen ein breites Spektrum an Atlassian Produkten und angebundenen Drittanbieter-Daten ab. Es ist damit besonders für technische Nutzer und Entwickler geeignet, die schnellen, strukturierten Zugriff auf relevante Daten benötigen, während Administratoren gleichzeitig detaillierte Kontrolle über Berechtigungen und Zugriffsbereiche behalten.
So können Agenten auf Informationen zugreifen, die nicht in einem einzigen Produkt vorliegen:
Welche Confluence Seiten hängen mit diesem Jira Epic zusammen?
Wer ist für diesen Service zuständig?
Welche Deployments stehen in Zusammenhang mit diesem Vorfall?
Darüber hinaus können so beispielsweise Wochenberichte erstellt werden, die sowohl Jira Tickets, zugehörige Änderungen in Confluence als auch Bitbucket Aktivitäten umfassen. Das CLI ist dabei nicht auf Lesezugriffe beschränkt: Entwickler können damit auch Beziehungen im Graphen anlegen, Arbeitselemente aktualisieren und Kontext aus eigenen Tools zurück in den Graphen schreiben.
Ein wichtiger Unterschied liegt in der Tiefe der Graph-Abfragen: Das Teamwork Graph CLI eignet sich besonders für mehrstufige, fein granulare Abfragen über Produktgrenzen hinweg. Solche Multi-Hop- oder Graph-Traversierungs-Szenarien sind hilfreich, wenn ein Agent nicht nur ein einzelnes Objekt auslesen, sondern Beziehungen über mehrere Stationen nachvollziehen soll – etwa von einem Jira Vorgang über verknüpfte Confluence Seiten und Pull Requests bis hin zu beteiligten Teams oder Deployments.
Typische Einsatzszenarien für das Teamwork Graph CLI:
Agenten laufen im Terminal, in CI/CD-Pipelines oder anderen Shell-fähigen Umgebungen
Ergebnisse mehrstufiger oder produktübergreifender Graph-Abfragen sollen lokal weiterverarbeitet, als JSON gespeichert oder in Automatisierungspipelines eingebunden werden
Die Teamwork Graph CLI ist übrigens nicht zu verwechseln mit der Rovo Dev CLI, die nur in Verbindung mit Atlassian's Coding Agent Rovo Dev funktioniert.
Der Rovo MCP Server – die Lösung für Web-Agenten und IDEs
Das MCP (Model Context Protocol) ist ein von Anthropic initiierter Open-Source-Standard, der es Agenten erlaubt, über einen einheitlichen Standard auf externe Datenquellen, Tools und Dienste zuzugreifen.
Atlassian stellt mit dem (Atlassian) Rovo MCP Server eine Implementierung dieses Standards bereit, die Atlassian Produkte und den Teamwork Graph für MCP-fähige KI-Assistenten wie Claude, ChatGPT und IDE-Integrationen wie Cursor zugänglich macht. Darüber hinaus ermöglicht der MCP Server Schreibzugriffe und umfassende Aktionen in Atlassian Produkten, sodass Agenten nicht nur Daten abrufen, sondern auch aktiv Inhalte erstellen und bearbeiten können.
Im Gegensatz zum CLI liefert der MCP Server vordefinierte Beschreibungen der verfügbaren Tools mit. Dadurch stehen dem Agenten Funktionen und deren Verwendung direkt zur Verfügung. Zudem sind die bereitgestellten Befehle häufig umfangreicher, sodass viele Abfragen in weniger Schritten ausgeführt werden können.
Ein Kostenvorteil ergibt sich daraus jedoch nicht zwangsläufig: Das Laden der MCP-Toolbeschreibungen erhöht den Tokenverbrauch und kann den zusätzlichen Aufwand durch Rückfragen beim CLI ausgleichen oder sogar übersteigen.
Im Gegensatz dazu müssen beim CLI alle Funktionen separat installiert und dem Agenten beispielsweise in einem Dokument zur Verfügung gestellt werden.
Typische Einsatzszenarien für Rovo MCP:
Webbasierte LLMs, IDEs oder Drittanbieter Sandboxen ohne Shell-Zugriff sollen auf Atlassian Daten zugreifen
Ein Agent soll automatisch Verantwortliche eines Projekts ermitteln, auch wenn diese nicht explizit dokumentiert sind
Ein Assistent soll Beziehungen zwischen Confluence Seiten und Jira Tickets nachverfolgen, um die ursprüngliche Informationsquelle zu identifizieren
Teamwork Graph API – Zugriff aus Forge Apps heraus
Die Teamwork Graph API ist derzeit über das Forge Early Access Program verfügbar. Nach aktueller Atlassian Dokumentation wird der Zugriff nicht als frei nutzbare, allgemeine HTTP-API beschrieben, sondern als GraphQL-Zugriff aus einer Forge App heraus – über @forge/api und requestTeamworkGraph. Dafür muss die App für das EAP freigeschaltet sein und je nach Zielprodukt die Scopes read:graph:jira oder read:graph:confluence im manifest.yml deklarieren.
Die API ist damit aktuell vor allem für Forge App- und Integrationsentwickler relevant, die Teamwork Graph Daten direkt in eigenen Atlassian Apps nutzen möchten. Atlassian weist außerdem darauf hin, dass Apps mit diesen Scopes Zugriff auf Teamwork Graph Daten organisationsweit erhalten können, dabei aber weiterhin Endnutzerberechtigungen respektieren. Während des EAP sollen solche Apps nur in Testorganisationen bzw. mit einem freigegebenen Pfad in Richtung Produktion eingesetzt werden.
Technisch kombiniert die API Cypher-Abfragen zur Graph-Traversierung mit GraphQL, um anschließend gezielt Felder der gefundenen Objekte abzurufen. Sie eignet sich daher perspektivisch für programmatische Multi-Hop-Abfragen aus Forge Apps heraus, ist aber aktuell kein allgemein verfügbarer Zugriffspfad für Endnutzer, beliebige Backend-Services oder einfache Agenten-Setups.
Fazit: Verschiedene Wege zum Teamwork Graph
CLI, MCP Server und API sind verschiedene Zugangswege zum selben Kern: dem Teamwork Graph. Das CLI eignet sich für Shell-basierte Workflows und tiefe Graph-Analysen, der MCP Server für die Integration in LLM-Hosts und IDEs. Die Teamwork Graph API ist aktuell vor allem für Forge Apps im Early Access relevant. Entscheidend ist weniger der Name des Werkzeugs als die zentrale Idee dahinter: Kontext aus der täglichen Zusammenarbeit strukturiert und systemübergreifend zugänglich zu machen.
