Model Context Protocol (MCP) and Rovo
The Atlassian Rovo MCP Server connects external AI platforms to Atlassian products—exposing graph-enriched data through a secure, standardized interface
Model Context Protocol (MCP) is quickly becoming the standard way AI systems connect to tools like Jira and Confluence—and Atlassian is leaning into it with Rovo.
MCP is not just another acronym or integration pattern. It represents a meaningful shift in how AI systems interact with the tools we use every day.
This article is intended to demystify MCP in practical terms, explain what Atlassian is doing with Rovo, and—most importantly—help you understand what this means for customers and partners working in and around the Atlassian ecosystem.
Model → refers to the AI model (e.g., GPT, Claude, Gemini)
Context → the data, tools, and environment the model needs to do useful work
Protocol → a standardized way for systems to communicate
Put simply, it’s a standard for how AI models access and interact with external systems—when those systems expose MCP-compatible interfaces (like Jira, Confluence, GitHub, etc.).
Note: My coworker, Aaron Geister, contributed to this article. Like me, Aaron is a Atlassian Community Champion.
Why MCP exists in the first place
Most of today’s AI experiences still have a gap: they’re powerful but disconnected.
You can ask an AI to summarize something, generate ideas, or even write code—but when it comes to actually doing work inside your systems (creating Jira issues, updating Confluence pages, checking service health), things tend to break down. You’re back to copying, pasting, and manually stitching together workflows.
Traditional integrations don’t really solve this. APIs are too low-level and require explicit programming. App integrations are usually point-to-point and don’t generalize well across systems.
MCP (Model Context Protocol) is an attempt to solve this problem in a standardized way.
Instead of building one-off integrations for every tool, MCP defines a common way for AI systems to:
-
discover what a system can do
-
access structured data
-
take actions safely
A helpful way to think about it: MCP is a standard interface layer that lets AI operate software systems more like a user would—just with better context and automation.
What MCP actually is (without the jargon)
At a high level, MCP introduces a few core building blocks:
-
Tools: actions an AI can take (create an issue, update a page, trigger a workflow)
-
Resources: data it can read (issues, documents, services, configurations)
-
Prompts: structured ways to guide how work gets done
If APIs are designed for developers, MCP is designed for AI systems acting on behalf of users.
That distinction matters. The goal is not just access—it’s usable access in a way that fits how AI operates.
Why MCP is suddenly everywhere
MCP has moved quickly from experimental to mainstream.
Most major AI platforms now support it in some form. More importantly, the pattern is converging: instead of each vendor building proprietary connectors, there’s a push toward a shared model where systems expose capabilities through MCP-compatible endpoints.
At the same time, we’re seeing a shift from local, developer-focused setups to remote, managed MCP servers designed for real enterprise use.
The practical implication is that AI is no longer confined to a single tool. It can operate across multiple systems at once—provided those systems expose themselves in a consistent way.
That’s where Atlassian comes in.
What Atlassian is doing with MCP
Atlassian’s Rovo MCP Server is its implementation of this pattern for Atlassian Cloud.
It exposes Jira, Confluence, Compass, and related data—often enriched with context from the Teamwork Graph. This includes both reading data and taking actions, depending on permissions.
This means you can use tools like ChatGPT, Claude, or Copilot to:
-
search and summarize issues or pages
-
create or update work items
-
interact with your system of record without switching contexts
At the same time, Atlassian is not positioning this as a closed ecosystem.
Rovo itself is evolving to connect to other MCP servers—things like GitHub, design tools, communication platforms, and internal systems. This is separate from how those systems may already contribute data into the Teamwork Graph via native integrations. Atlassian is therefore both:
-
exposing its own data via MCP
-
consuming other systems via MCP
That dual role is important.
How Teamwork Graph fits
If MCP is one of the primary ways AI connects to systems, Teamwork Graph is what makes those connections meaningful.
Atlassian’s Teamwork Graph is the underlying data and relationship layer that connects work across Jira, Confluence, and other tools—mapping relationships between people, projects, and knowledge.
Rovo doesn’t look at systems in isolation. It uses the graph—a structured, permission-aware map of how your work actually fits together—to understand context and deliver more useful results.
This is an important distinction.
-
MCP gives AI access to systems
-
Teamwork Graph gives AI context about how those systems relate
Without that context, AI can retrieve information. With it, AI can understand how work connects—and act accordingly.
A helpful way to think about it:
Teamwork Graph is how Atlassian products connect and understand work across everything in the graph. MCP is how AI systems interact with that understanding.
There’s an important nuance here. MCP does not expose the Teamwork Graph as a standalone data layer. Instead, it exposes Atlassian product data (like Jira issues and Confluence pages) that has already been enriched by the Teamwork Graph.
In practice, this means AI can access relationships—like linked pull requests, deployments, or related work—but only when those relationships are surfaced through Atlassian objects. MCP is not a general-purpose gateway to every external system connected to the graph, nor does it expose those systems directly.
Data from tools like GitHub or Slack becomes available through MCP only insofar as it is connected to and surfaced through Atlassian products within the system of work.
If you want to better understand how Teamwork Graph works with Rovo, I covered it in more detail here:
👉 How Teamwork Graph Powers Rovo
Where Atlassian is focusing (and why it matters)
The interesting part of Atlassian’s approach is not just that it supports MCP—it’s how it’s implementing it.
There’s a clear emphasis on enterprise concerns:
authentication models (OAuth and API tokens)
permission inheritance from existing Atlassian access controls
domain restrictions and admin policies
auditability of actions taken through MCP
This aligns with a broader reality: the biggest barrier to enterprise AI adoption isn’t capability—it’s trust and control.
Atlassian appears to be designing MCP as a governed extension of the existing system of work, rather than an open-ended integration layer.
What this means for Atlassian customers
The most immediate impact is that your Atlassian data becomes directly usable by AI systems.
Jira issues, Confluence content, and service data are no longer just things people interact with—they become inputs and outputs for automated workflows driven by AI.
This changes how you think about value.
Well-structured issues, consistent naming, and clean documentation aren’t just “good practice” anymore. They directly influence how effective AI interactions will be.
There’s also a shift in how workflows happen.
Instead of building separate automations in each tool, you can start thinking about cross-system workflows where AI coordinates work across Jira, documentation, code, and communication tools in a single flow.
What this means for Atlassian partners and builders
For Atlassian’s partners, MCP introduces a new layer to consider when designing solutions — and this is good news for Atlassian’s customers.
There’s an opportunity to expose additional systems through MCP, making them accessible to AI in the same way Atlassian is doing. This could include internal tools, industry-specific systems, or extensions to existing Atlassian workflows.
Not all connected systems are accessible through MCP. What matters is whether their data is surfaced through Atlassian products—only then can it be accessed by AI via MCP..
It also changes the nature of app development.
Instead of focusing only on UI and APIs, there’s increasing value in:
-
defining useful tools and actions
-
structuring data in ways AI can consume
-
designing workflows that assume an AI “operator” is part of the process
In other words, the world is moving toward environments where multiple MCP servers coexist, and AI systems orchestrate work and analysis across them.
A realistic view of where things stand
Let’s be clear: when it comes to leveraging MCP, it’s early days.
The core ideas are solid, and the ecosystem is evolving quickly. However, there are lots of rough edges in areas like:
-
consistency of behavior across tools
-
formatting and content handling
-
performance and reliability (in some cases)
-
governance across multiple MCP servers
MCP is best understood as emerging infrastructure—not a finished, fully standardized layer yet.
That doesn’t reduce its importance. It just means expectations should be calibrated accordingly. And the evolution of MCP-enabled systems is something we all need to watch closely.
How to get started
If you’re working in Atlassian today, the best way to understand MCP is to try it.
Start simple:
-
connect an external AI tool to the Rovo MCP Server
-
explore read-only use cases (searching, summarizing, analyzing)
-
gradually test write actions where appropriate
From there, identify workflows where AI could realistically save time or improve consistency.
For partners, the next step is to think about what systems or capabilities you can expose in a similar way, and how those could integrate into broader AI-driven workflows.
Closing thoughts
MCP is not just another integration standard. It’s part of a broader shift toward AI systems that can operate across disparate systems, not just within them.
Atlassian’s role in this is significant because of where it sits: at the center of how many organizations track and manage their work, knowledge, and operations.
By making its system of work accessible through MCP, Atlassian is effectively turning its products into part of a broader infrastructure that AI systems will rely on.
The bigger picture is not about a single tool or platform winning.
It’s about a world where systems expose capabilities in a consistent way, and AI can move across them to get work done.
MCP is one of the clearest signals I’ve seen that things are moving in the right direction. And the AI-forward leaders among us are paying close attention.
📚 Further Reading
- This article is part of an ongoing AI & Rovo Article Series exploring responsible AI adoption.
See also...
-
What is the Teamwork Graph? — Official overview of Atlassian’s underlying data layer and how it connects work, knowledge, and teams
-
Introducing the Model Context Protocol — Anthropic’s original announcement and framing of MCP as an open standard for connecting AI to real-world systems
-
Model Context Protocol (MCP) Explained — A vendor-neutral perspective on why MCP is becoming foundational for enterprise AI, enabling standardized access to tools, data, and services
About the authors
Dave Rosenlund and Aaron Geister are Atlassian Community Champions. Dave is the founder of the virtual Atlassian Community Events chapter, CSX Masters (fka ITSM/ESM Masters). He also helps the Program/Project Masters chapter and the Boston ACE. Aaron is the leader of the Central Wisconsin ACE.
In their day jobs, they work for Platinum Atlassian Solution Partner, Trundl.
Was this helpful?
Thanks!
Dave Rosenlund _Trundl_
1 comment