Hi Community,
I've been learning about both native Rovo connectors and the new MCP integration, and I'm trying to understand where each one fits best.
If both can give Rovo access to external information, when would you choose an MCP server instead of using a native connector?
Are there specific use cases where MCP provides more flexibility or better control, or are native connectors generally the preferred option whenever they're available?
I'd love to hear how others are making this decision in real projects.
Thanks in advance!
Thats thoughtful question. Here is my breakdown
| Strategic Goal | Recommended Path | Why? |
|---|---|---|
| We want Atlassian Rovo to search our Google Drive, Slack, and Figma. | Native Connector | Fully managed, zero maintenance, handles indexing and permissions natively within Atlassian Cloud. |
| We want developers using Cursor/Claude to pull Jira specs while coding. | Atlassian Rovo MCP Server | Connects Atlassian context directly into external AI environments over secure OAuth 2.1. |
| We want an AI agent to query an internal, on-prem database. | Custom MCP Server | Easy to build, runs locally or within your private network, and conforms to open standards. |
| We need automated AI pipelines to trigger complex workflows across multiple tools. | MCP Integration | Standardised tool invocation designed specifically for multi-step agentic execution. |
Most engineering leaders start with Native Connectors for broad organisation-wide knowledge retrieval (giving all employees search across common SaaS apps), while reserving MCP for deep technical workflows, developer tooling, and custom internal integrations where specific actions or non-standard data sources are required.
In short: Native Connectors pull external knowledge into Atlassian to make Rovo smarter. MCP projects Atlassian context and actions out into external AI clients and custom developer workflows.
The main difference is that Rovo connectors index the 3rd party data into the Teamwork Graph for permanent access while MCP connections only provide data/actions on demand.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One rule of thumb I've found useful is: if a native connector already supports the system you need, I'd start there. You get a managed integration with less operational overhead.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.