Q1: Today Forge actions get invocation context that tells you the source (Rovo agent, Automation, etc). The exact attribution metadata shape for MCP-invoked tools isn’t fully specified yet. Flagging this as something we will explore.
Q2: Agreed. The description field currently serves both admin UI and LLM selection, which are different jobs. We will add a human-readable description for admins + an aiDescription optimised for tool selection.
Q3: There is no built-in mechanism today beyond admin toggles (enable/disable per tool). As more apps expose tools this we will need a better answer (grouping, namespacing, contextual filtering).
@raimonds.simanovskis Great to hear you are interested!
Tool discovery: Rovo uses progressive disclosure. Only lightweight metadata (name + short description, ~50-100 tokens per tool) is loaded at discovery time. Full schemas are hydrated only when a tool is selected. So 7+ tools won’t pollute the context.
Many tools vs single tool: We recommend individual tools. A single tool with an action parameter hides capability from the discovery layer and forces two-step reasoning. Admin controls (enable/disable) will also operate at the individual tool level.
On manifest versioning: Tool definitions (name, description, schema) are part of the manifest today, so changes require a new version. However, the upcoming rovo:skill module addresses the dynamic instructions problem. Skill content is deployed as a resource file, not in the manifest, so you can update the “when and how to use eazyBI” guidance on each forge deploy without publishing a new app version. We have a separate RFC for skills here: RFC-137: Forge Module for AI Skills
Recommended approach: Define individual actions under rovo:mcp for precise tool selection, and pair with a rovo:skill for dynamically updatable instructions that teach when and how to use your tools together.
Thanks everyone for the feedback on this RFC. The discussion period has closed and we’re moving to resolve.
Key themes from feedback:
-
Tool discovery and selection - How does Rovo pick between tools with similar descriptions? How does it handle overlap with native capabilities? No built-in priority today; clear descriptions win. This needs more thought as the ecosystem scales.
-
Admin governance - Default state on install, what happens when new tools are added post-install, opt-in vs opt-out. Aligning with existing Connected Apps patterns but specifics need to be locked down.
-
Description overloading - The description field serves both admin UI and LLM selection. These are different jobs and should likely be separated.
-
Invocation attribution - Developers need a clear way to distinguish which surface invoked their tool (Rovo Chat, external MCP client, Automation) for adoption analytics.
-
Crowded tool space - As more apps expose tools, we need better answers for grouping, namespacing, and contextual filtering beyond admin toggles.
-
Async/long-running tools - Timeout contract for MCP-invoked actions needs to be specified, especially for heavy workloads like exports.
-
Module limits - rovo:mcp is one module per manifest so it doesn’t blow the cap, but apps already near the limit should flag this.
What we’re doing next:
-
Proceeding with the rovo:mcp module design as proposed
-
Addressing the open questions above in implementation design docs
-
The companion rovo:skill RFC is live for feedback here: RFC-137: Forge Module for AI Skills
-
EAP targeting later next quarter
Hi @DeanPeach,
I’m coming back to this thread now that rovo:mcp is in Preview.
The EAP announcement included a “More details” note stating you were working on enabling the module to expose defined actions as tools to third-party coding agents (Claude, Cursor) via Atlassian Rovo MCP. That note is absent from the Preview announcement, and the current module documentation describes only Rovo Studio custom agents. The https://mcp.atlassian.com/v1/forge/<installationId> endpoint shape from this RFC doesn’t resolve, and there is no admin-side surface for exposing tools externally.
Could you clarify whether external MCP client exposure is still in scope ahead of GA and when we could expect it?
Hi @DominikPatrzek
Thanks for the follow-up!
The Preview release scoped rovo:mcp to custom Rovo agents. External client support (Claude, Cursor, etc.) is the next phase, actively in development. When it lands, the experience will include a dedicated per-app endpoint with the following shape: https://mcp.atlassian.com/forge/v1/{appId}, an admin toggle to control external exposure to all tools, and an OAuth consent flow for user authorisation.
The good news: you can start today, and it sets you up for everything that follows.
Adding rovo:mcp to your app now makes your tools available in Rovo agents which is the same underlying infrastructure that will power external client access. When we open the EAP for third-party client support, targeting September, your app should be ready without any additional development work.
This next phase of external MCP client access will be run as an EAP but the plan is to accelerate it to Preview as we get feedback. EAP sign-up form here