[Preview] Atlassian Rovo MCP v2

[#1]

Hi everyone,

We’re excited to share that a preview release of our new Atlassian Rovo MCP is now available for early access.

This release introduces some significant changes including:

• Dozens of new tools abstracted behind discover and execute tools, lazy loading tools when required to reduce up-front context window consumption by >50%.

• New and improved Confluence tools, now with support for attachments, databases, whiteboards, and more, so your AI can work with the full picture in Confluence, not just page text.

• Optimised and improved tool responses, substantially reducing context window consumption from tool invocations.

The preview endpoint is now available at https://mcp.atlassian.com/v1/mcp/preview and can be utilised today. Over the coming weeks we’ll be adding and improving more tools to this endpoint in the lead up to a broader release.

For more details about the preview you can reference our documentation or list of preview tools. The Atlassian Rovo MCP changelog will keep you informed of any future updates.

Please Note: This is a Preview release of the Atlassian Rovo MCP v2. This endpoint is considered early access and will be subject to change; including the MCP tools and their responses. Please share any feedback, bugs or learnings you have in this thread.

[Michael Branders]

Is there any new or update about adding bitbucket to OAuth as well and not just token authentication? 

[Cory Beck]

@Sean Bourke ,

The >50% context reduction and the Confluence attachments/database support are genuinely helpful, thanks for shipping these. One gap I want to flag: the post is all efficiency and coverage, and it doesn't mention reliability. The recurring complaint in this group has been connection stability on the current endpoint, 401s after token refresh and 'Session not found' errors that force a reconnect. Does the v2 preview sit on the same session infrastructure as GA, or a reworked one? If it's the same backend underneath the new tooling, my assumption is the drops persist regardless of the context improvements. Happy to be wrong on that. Would help to know before we evaluate the preview.

[Nicola Pacini]

Hi @Sean Bourke  thanks for the important update. I was wondering if the 2 versions could somehow coexist or this approach is not recommended?

Thanks!

[Sean Bourke]

Thanks everyone for the questions and feedback. I've responded to each of the questions in this comment.

@Michael Branders while this is an early release, we believe this approach will unlock the ability to deliver more tools for more products. We're exploring bringing Bitbucket into the folk; but there are a few things which we need to solve first (for example, Bitbucket requires selection of a workspace rather than a site).

@Cory Beck the v2 update exists on our new DCR OAuth endpoint which should drive some improvements while also providing us deeper insights. We also made some improvements back in March which should have improved the token refresh for many MCP clients. If you're still experiencing these, please reach out to me at sbourke@atlassian.com, as we're keen to explore and understand any circumstances of this further.

@Nicola Pacini for now this version is a preview endpoint for feedback. Longer term, we will likely seek to replace our v1 API with this one (rather than a full deprecation); however we need to navigate some complexities related to MCP client OAuth + tool caching. As we formalise a better view of how this will occur once we move to GA, we'll be able to share more concrete details. Out of curiosity; do you see any benefits to having both v1 and v2 separate? 

[Nicola Pacini]

Hi @Sean Bourke I'm interested in testing the v2, but I'm concerned about potential overlap on the available tools, so I'm thinking about how to use them separately. I'm using Kiro right now and I was thinking to use it in different workspaces or enable them 'on demand'.

What do you think?

[Sean Bourke]

@Nicola Pacini thanks for the clarification. If you still have the v1 tools declared, you're likely to run into conflicts where it will refer to those tools instead - for example, it may request `createConfluenceContent` on the older v1 version rather than the new one which supports databases and whiteboards.

The most ideal approach would be to just use v2 Preview independently to test it; otherwise you may be able to use them concurrently and just ask the LLM to explicitly utilise the v2 Preview based upon the name you use to declare it.

[unsafe9]

Big thanks to the team for the great work.

Personally, I'm not a fan of the discover-execute approach. If the goal is to reduce context window usage, that should be the responsibility of the MCP clients. Tools like Claude Code and Codex can already search for tools on demand without loading them at startup, which is fast and accurate because the models are specifically fine-tuned for it. On the other hand, if this approach is intended for fine-grained permission control, offering a dynamic tool list would be a better solution.

Additionally, I'd love to have an option to adjust the page width when creating or updating a page.

[Sean Bourke]

Hey @unsafe9

Thanks for the feedback and appreciate the perspective of some MCP clients providing tool-name level search to support tool discovery without loading full tool context.

The upcoming MCP release candidate implements SEP-2549 which brings us improved controls related to per-user tool caching (i.e. controlling whether MCP clients cache this globally or on a per-user level). If you had the option to select which the products you use the most and expose these to your client, with the remainder being available via discover-execute, would that help balance things?

[unsafe9]

Hi @Sean Bourke ,

As I understand it, the new caching specification makes `tools/list` cheaper and safer to refresh, but it does not change which tools are exposed directly.

Being able to select product-level subsets would help somewhat, but my preference is still for the full authorized tool list to be exposed directly by default. For clients that prefer a smaller context usage, maybe the curated subset plus discover/execute approach could be offered as a separate compact mode.

The point is that I think an MCP server should expose its full capabilities, and MCP clients should decide how to present, search, cache, or prioritize them. I’d prefer not to have the server impose an extra indirection layer on all clients when some clients can already manage large tool catalogs effectively.

[dtaylor]

Hello!

I am exploring the use of Confluence Databases to document product requirements - the ability to link individual rows / requirements is a game changer.

While the v2 MCP technically supports databases, the support is limited to reading the entire table. The lack of tooling for individual row operations (read / write) defeats my entire use case.

Are these features on the roadmap by chance?

[Josh]

Hi @Sean Bourke - do any of the upcoming MCP enhancements for v2 include more granularity around permissions, boundaries, or governance?

For example, the allow list for MCP actions (e.g. READ JSM requests) currently applies across an entire instance. This may be acceptable for customers with fairly homogenous risk profiles within an instance. However, orgs with varied risk profiles from space to space don't really benefit from the coarse controls.

Another example is Atlassian's fundamental concept that MCP tools should inherit all human user permissions when authenticating via OAuth. The blast radius for MCP tools is likely orders of magnitudes larger than what a human can perform via the UI (with many built-in guardrails / warnings). I'm aware of the API token scope option, which is helpful, but additional access granularity or a concept of "protected spaces" would go a long way to making MCP adoption safer.

[Jemma Swaak]

Hi @Josh - Jumping in from the controls side as another Product Manager working on the Atlassian Rovo MCP server. Thanks for your feedback! We are actively investigating how we make our permissions control more granular rather than being scoped to an org-level. I'd love to chat to more about your use cases if you are open to it: https://calendar.google.com/appointments/schedules/AcZssZ2jJUx4vpkF9heWKnydjvS80dzD2UTGpePLYuOhSFkrFd_bZCInhwkoACBgDeyP4dIax7JghnMS

[Rebekka Heilmann _viadee_]

Hey guys,

we are encountering issues with using MCP with Service Account Tokens. SA Tokens need to be scoped, but MCP seems to require different scopes than API does. Will required scopes for tools like TWG access be added eventually? Is there any work around?