RFC-134: Forge Rovo Tools and MCP

[DeanPeach]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

---

Project Summary

Apps built by our developer and marketplace communities are integral to the day-to-day work of our shared customers. As AI continues to change the shape in which these users work, it’s important that we enable apps to keep up.

• Publish: 13 May 2026

• Discuss: 27 May 2026

• Resolve: 16 Jun 2026

Problem

Today Forge apps are only able to define actions which are exposed and selectable by customers when creating agents, but not natively available while interacting with Rovo. This results in additional complexity or limitations to adoption, as customers can only utilise these actions when chatting with Agents, not the core Rovo experience.

Similarly, we are seeing apps exploring pathways to delivering MCP capabilities for their apps. For remote apps which store this data today this is achievable, however apps which store data within the Forge platform inherit additional complexities to exposing such capabilities. As users evolve into differential ways of working, it’s important that apps are able to embed themselves into user’s day to day experiences.

Proposed Solution

How a tool is defined

• Tools are not a new primitive, they will reuse existing Forge actions. An action becomes a tool when it is referenced by a rovo:mcp module in the manifest. This means:
  • No new runtime concept actions already have defined inputs/outputs, permissions, and execution context
  • Existing apps get a path to MCP if they already have actions, wiring them up is a manifest change
    Manifest example:

modules:
  rovo:mcp:
    - key: my-app-mcp
      tools:
        - summarise-page
  action:
    - key: summarise-page
      function: summarise-page-handler
      actionVerb: GET
      name: Summarise page
      description: >-
        Returns a concise summary of a Confluence page
        given its page ID. Read-only.
      schema: summarise-page
  function:
    - key: summarise-page-handler
      handler: src/handlers/summarise.handler

schemas:
  - key: summarise-page
    inputSchema:
      type: object
      properties:
        pageId:
          type: string
          description: The ID of the Confluence page to summarise
      required:
        - pageId
      additionalProperties: false

How tools are exposed

Actions defined by a Forge app become tools when they are referenced by a rovo:mcp module.

• Rovo and MCP (rovo:mcp): When an action is listed under a rovo:mcp module, it is exposed as a managed MCP tool on Atlassian MCP infrastructure. Rovo can discover and invoke those tools, and external AI clients such as Claude Desktop, Cursor, or custom agents can connect using the standard MCP protocol. We handle the complexities of running the MCP layer: auth, tool discovery, and protocol negotiation so developers can focus on building actions that help customers get work done.

Note: this does not initialise an independent MCP server per app, it exposes the referenced actions as tools on the existing Atlassian MCP infrastructure.

Each app with externally exposed tools inherits a unique URL that end-users can use to configure their client. This URL will take the form of https://mcp.atlassian.com/v1/forge/<installationId> or https://mcp.atlassian.com/v1/forge/<appId>.

Auth is backed by Atlassian’s OAuth service. The authenticated user’s identity is passed through to the invocation context, so asUser() requests respect the end-user’s access permissions, the same trust model as Rovo. asApp() will be actively prevented for MCP-invoked actions to preserve the permissions model.

Similar to Atlassian’s own Rovo MCP, end-users will be able to select which tools are enabled or disabled and whether new tools are automatically discovered.

Apps expose actions as tools by referencing them from rovo:mcp. Admins retain control over which tools are enabled on their site, consistent with existing Forge governance.

What’s gonna happen to actions?

Existing core:action and automation-action modules will continue to work. We are not deprecating actions as part of this RFC.

There is no new tool module in this proposal. Actions remain the executable capability, and rovo:mcp is the module that determines which actions are exposed as tools.

For apps with existing actions, there is no migration to a new tool primitive. Developers can expose existing actions as tools by referencing them from rovo:mcp, while keeping the same action handlers, permissions, and invocation context.

Admin Experience

Similar to Atlassian Rovo MCP and Forge REST APIs, it is important that we provide opportunities for admins to control which tools are exposed and available both within Rovo and on their site to external MCPs.

We are proposing that admins will have toggles similar to the Forge REST API service, enabling a pathway to support Rovo MCP on apps which are Runs on Atlassian.

Example use case

A Forge app defines a summarise-page tool that takes a pageId and returns a plain-text summary.

A user asks Rovo: “Summarise the design review page.” Rovo discovers the tool, invokes it with the user’s identity, and returns a permission-scoped summary, no custom agent required.

The same tool is also available via the app’s remote MCP endpoint. A user connects their preferred AI client, asks the same question, and gets the same result.

Asks

We are open to all feedback exploring alternatives, constraints, opportunities and agreement with the proposed solution. In particular, we’d be keen to learn:

1. Does the proposed solution meet your needs for exposing tooling to users utilising AI tools?

2. Can you think of any use cases which may not be achievable through this approach?

3. Do you have an interest in exposing tools to either Rovo or remote MCP clients?

[danielwester]

Hi @DeanPeach ,

Thank you for this RFC. We’d defnitivley be interested in exposing tools to Rovo and remote MCP Clients. Our current challenge with MCP Servers is interaction with Atlassian and this seems like it would allow for us to be at the same level as the Atlassian tools in regards to MCP (so we don’t have to create our own “update comments on Jira page” tool).

The only challenge/concern we have (based on today’s situation with Rovo agents/skills) is that the description is being shared between the LLM and the Human (as well as the lack of branding which helps to inform folks who’s tool is who’s). Can this be taken care of in day 1 with this solution? For example:

odules:
  tool:
    - key: summarise-page             
      name: Summarise page
      icon: Icon here
      description: This skill does something really cool and this text is here for the human reading it....
      function: summarise-page-handler
      schema: src/schemas/tools.json
      actionVerb: GET
      exposure:                       
        rovo: true             
        atlassian-mcp: true

[tbinna]

We were just working on implementing automation actions for our app. This post makes me hesitate to proceed. Could you please share a few more details on the thinking of the API surface going forward?

Currently, the action module can be shared between automation actions and Rovo agent actions.

We expect most developers building new AI-facing capabilities will use tool going forward.

For apps with existing actions, we will provide a migration path from core:action to tool .

I don’t quite understand from these two quotes whether the idea is that both Rovo agents and automation will continue to share the implementation going forward via the tool module, or they will become two separate things.

[YuriyBilash]

Hi @DeanPeach,

Just for my understanding, do we still need to define the rovo:agent module alongside this new tool module in order to expose our tool in the native Rovo experience? I’m asking because rovo:agent supports custom prompts, which allow us to instruct Rovo to validate user input, control how action outputs are presented, and similar behaviors.

For example:

• If a user invokes our action without a required input parameter, we can display a message such as: “Please provide the required input parameter…”

• If a user invokes our action successfully, we can instruct Rovo to present the results in a tabular format with columns such as “A”, “B”, and “C”.

If the tool module no longer requires rovo:agent, I would expect it to provide an equivalent to the rovo:agent prompt property, where we could define how the tool module output should be formatted, etc.

Also, do you have plans to support Forge Remote endpoints in addition to Forge functions within the tool module, similar to what the current action module supports?

  - key: my-awosome-action
    name: My Awesome Action
    endpoint: my-awesome-action-endpoint # Remote endpoint
    actionVerb: GET
    description: My Awesome Action Description.

[tbinna]

Hey @DeanPeach, could you please help with the questions that have been asked so far? This will help us understand how the proposed feature integrates into the existing landscape. Once we have that, it will be easier to comment on the RFC requests themselves.

Thanks!

[DeanPeach]

Hi @tbinna thanks for flagging this, the earlier wording was misleading and we’ve updated the RFC.

We initially explored introducing a new tool module as the evolution of actions, but it would have meant two modules doing similar things and a migration burden for existing apps. Instead, we’ve landed on keeping action as the single module shared across automation, Rovo agents, and (when referenced from rovo:mcp) tools in Rovo and MCP.

So no new module and no migration. Please keep building your automation actions as planned, exposing them as tools later should just be an additive manifest change (a rovo:mcp entry referencing the action key).

[DeanPeach]

Hi @YuriyBilash thanks for the questions!

Onrovo:agent vs tools: With this proposal you don’t need to define a rovo:agent to expose a tool in the native Rovo experience, referencing the action from rovo:mcp will be enough for Rovo to discover and invoke it. That said, rovo:agent isn’t going away, and it’s still the right module when you want custom prompts, validation behaviour, or specific output formatting around your action. The two can coexist: the same action can be exposed as a tool in Rovo and used inside an agent with a custom prompt.

We don’t currently plan to add a prompt-equivalent property on the tool side. For input validation, you can express required fields and constraints in the action’s input schema, and Rovo will handle prompting the user for missing inputs. For richer output formatting or behavioural control, rovo:agent remains the right tool.

On Forge Remote endpoints: Since tools reuse the existing action module, anything action supports today (including endpoint for Forge Remote) will carry through unchanged.

[DeanPeach]

Hi @danielwester thanks for the feedback!

Branding: App-level attribution (your app name + icon shown alongside tools in the Rovo UI and MCP tool listings) is something we’ll handle at the platform layer. Your app already declares these, so we’ll surface them wherever tools appear.

Descriptions: In your example the description is aimed at the human, but the LLM also needs a description to decide when and how to invoke the tool and those two audiences often want very different things (concise and friendly vs verbose and instruction-heavy). Would a dual-field approach work for you? Something like:

• description LLM-facing (optimised for tool selection and invocation)
• userDescription human-facing (what shows in tool pickers, consent screens, admin hub)

Would that solve your concern, or do you see cases where a single field serving both is preferable?

[raimonds.simanovskis]

@DeanPeach We are interested in providing tools to Rovo agents from our eazyBI app. In our case, there could be quite many detailed actions that we want to expose (so that agents could find eazyBI reports and dashboards and export their results to different formats), like:

• list_accounts
• list_reports
• show_report
• export_report
• list_dashboards
• show_dashboard
• export_dashboard
• …

Each tool will have many input parameters and a description. I’m wondering how Rovo discovers the tools and when they are included in the LLM context? As our app tools are typically not needed by Rovo agents, we do not want to pollute the context with lengthy tool descriptions.

The other concern is that tool definitions and descriptions are part of the manifest, and any change requires publishing the new version.

Currently, we have created an eazybi CLI for our app, and it also includes a skill that can be installed in coding agents, including Rovo Dev.

So I’m wondering if maybe a better approach is to create a single eazybi tool that will have these individual actions as an input parameter (similar to our single CLI tool with different arguments). And in addition, it could have a help action parameter that could be used to get the detailed skill description when needed, and then it would be easier for us to dynamically maintain this skill description without updating the manifest and publishing a new version.

Which approach would be better from the Atlassian / Rovo point of view? And can you provide more details on how tools by apps are discovered and loaded in the context of Rovo?

[YuriyMarchenko]

Hi @DeanPeach

@DeanPeach

Do you have an interest in exposing tools to either Rovo or remote MCP clients?

We’d love to have this ability! Thanks!

[Shu]

@DeanPeach currently Rovo actions w/ actionVerb other than GET can’t be called in an automation flow via Rovo agent, will this restriction be relaxed for MCP tools?

[billjamison]

Overall, the idea seems good - a straightforward way to expose app-specific functionality to agents. Questions, though, are

1. One function can be exposed through multiple mechanisms - how do we tell which mechanism the customer used? We want to understand adoption.
2. As mentioned already, tool description is overloaded, and probably should be separated into an admin-facing value and an agent-facing value.
3. A customer with multiple apps may have a crowded action / tool space. Is the customer expected to understand this and be specific? Or is there some mechanism that is supposed to help customers with this?

These apply to tools and actions.

[janette]

Hi,

This interesting and we can see use cases for this.

1. Can you elaborate how Rovo “decides” when to trigger the tool? If it’s based on description, is there a limit for how long the description can be? What happens when two apps have very similar descriptions?
2. Will Rovo favor the the internal or external tools? For the summarization example, given that Rovo also has the capability to summarize pages, would this need to be manually triggered by the user?
3. For Runs on Atlassian apps, will the admin need to enable the tools one by one? Is this opt-in, and at which state? Installation? What happens when a new tool is added into the app after installation? Will the tools be disabled by default?

[ErickaBastias]

Hi @DeanPeach and team,

At K15t we’ve been building toward making Scroll Exporters (PDF, Word, HTML) triggerable from Rovo and Atlassian Automations.

The tool module would unblock two things for us:
• Users interacting with Scroll Exporters through Rovo without needing to create a custom agent first
• Users interacting with Scroll Exporters through their AI client of choice (Claude, Cursor, etc.) via the Atlassian MCP, without us having to maintain a separate MCP server

We still have an open blocker on the Automation side: automation actions are Jira-only and doesn’t work in Confluence. Since Scroll Exporters lives in Confluence, we can’t expose our export action in the rule builder today. We’d love to know where that’s on the roadmap separately.

A few open questions:

1. Confluence support from day one? Or is this initially Jira-scoped like automation-action?

2. Tool routing when capabilities overlap: Some of our actions overlap with native Confluence features (e.g. exporting content). When a prompt could match both a native capability and a marketplace tool, what determines which runs?

3. User-facing tool identity: Can users explicitly invoke a specific app’s tool and have Rovo honor that?

4. Async / long-running tools: Our exports can take time on large spaces. Is there async/callback support, or do tools need to complete within a given time window?

5. Tool response types: Can tools return structured data like download URLs, not just plain text? And is file attachment support on the roadmap?

Happy to share more detail or participate in early access testing.
K15t team

[danielwester]

Yes the description approach you’re describing would work.

I want to note though - that the platform today doesn’t take care of the identity in Studio etc.

[DanielChodkowski]

We’ve already received questions from our customers asking whether our apps support MCP, so the timing of this RFC is spot on. The demand is clearly there.

The majority of our products are built on Forge, and staying Runs on Atlassian (RoA) is a priority for us — so the idea of exposing tools via rovo:mcp without leaving the Forge ecosystem is a great fit. We’re very supportive of the proposed approach.

One pain point we’re currently dealing with: customers who want MCP-like capabilities today are forced to build their own MCP layer and integrate with our apps through the Forge REST API. It works, but it adds significant complexity on their end and creates friction in adoption. This RFC would solve that cleanly.

A couple of questions from our side:

1. Will existing actions already used in app-based Rovo Agents also respect the proposed approach with schemas? We want to make sure there’s a consistent contract across both surfaces.

2. With the introduction of additional modules like rovo:mcp, schemas, are there plans to increase the module limit per app? Currently the cap is 150, and as we wire up more capabilities, this could become a constraint.

[DeanPeach]

@Shu yes this restriction being relaxed is currently work in progress.

[DeanPeach]

@DanielChodkowski

One pain point we’re currently dealing with: customers who want MCP-like capabilities today are forced to build their own MCP layer and integrate with our apps through the Forge REST API. It works, but it adds significant complexity on their end and creates friction in adoption. This RFC would solve that cleanly.

A couple of questions from our side:

1. Will existing actions already used in app-based Rovo Agents also respect the proposed approach with schemas? We want to make sure there’s a consistent contract across both surfaces.

2. With the introduction of additional modules like rovo:mcp, schemas, are there plans to increase the module limit per app? Currently the cap is 150, and as we wire up more capabilities, this could become a constraint.

Thanks for the feedback, and yes, the “build your own MCP + Forge REST API” friction is exactly what this aims to solve.

On Q1: Yes. rovo:mcp references existing rovo:action(s) by key. The schema evolution which will eventually be a separate file applies uniformly across all surfaces.

On Q2: rovo:mcp is one module per manifest. It just lists action keys, so adding 10 tools still only costs 1 extra module. The actions themselves count individually, but if they already exist for your agent there’s no additional cost. If you’re approaching the 100-module cap for other reasons, let us know. We’re exploring sidecar patterns to decouple count from manifest size.

[DeanPeach]

Thanks for the detailed feedback! The Scroll Exporters use case sounds like a great fit for this!

On the automation-action Confluence gap: that’s a limitation of the Automation surface specifically, not this proposal. rovo:mcp exposes tools through Rovo Chat and external MCP clients, both of which are product-agnostic. Your Confluence-based export action should work on day one through those paths.

On your questions:

1. Confluence support: Yes. rovo:mcp tools are invoked through Rovo and external MCP clients. There’s no Jira-only scoping here.

2. Tool routing with overlap: Tools are selected from a flat list based on descriptions. There’s no hard priority between native and marketplace tools today. Clear, specific descriptions are what drive correct selection. Admins will also be able to enable/disable tools at the site level if they want to control which tools are available.

3. Explicit invocation: Users can configure custom agents with specific tools, which narrows the selection set. Whether users can explicitly name a tool in freeform Rovo Chat (like a slash command) for 3P tools is something we’re still working through.

4. Async / long-running: Good question. Forge functions have execution time limits today. We need to clarify what the timeout contract looks like for MCP-invoked actions, especially for use cases like large space exports. Flagging this as something we should address in the design.

5. Response types: MCP supports structured content types, so returning a download URL in a structured response should be feasible. File attachment support (returning binary content directly) is not something we’ve scoped yet but worth considering.

[DeanPeach]

Q1: Tools are picked based on name + description from a flat list. Descriptions should be concise (roughly 40-100 tokens) and we will most likely enforce such a limit. When two tools have similar descriptions, there’s no deterministic tie-breaking today.

Q2: There is no built-in preference. Admins can disable specific tools to control this, but there’s no “prefer native” weighting. Whether we should add one is an open question.

Q3: The design aligns with existing 3P MCP server controls in Connected Apps (per-tool toggles). The exact defaults (opt-in vs opt-out on install, what happens when new tools are added post-install) aren’t locked down yet. There will probably be a toggle for “automatically discover new tools” option though.