GitLab MCP (Model Context Protocol) integration for Rovo Agents

[В_ячеслав Плахутін]

I am reaching out to inquire about the availability of a GitLab MCP (Model Context Protocol) integration for Rovo Agents.

Context and Use Case:
I am building a Rovo Agent designed to analyze engineering team performance by retrieving detailed data from GitLab - specifically commits, merge requests, and pipeline statuses associated with individual engineers. This would enable automated work analysis, progress tracking, and reporting across Jira issues and GitLab activity.

Current Limitation:
I have successfully configured the GitLab connector via Teamwork Graph, which is actively syncing (2,378 objects indexed). However, this connector only enables search and discovery of GitLab content. It does not provide the direct API-level access required for my use case - such as querying commits by author, filtering merge requests by date range, or retrieving pipeline details programmatically.
To achieve this, I would need a GitLab MCP server integration, similar to what is currently available for Bitbucket and GitHub within Rovo. I have explored the option of adding a custom MCP server, but the current requirements (Streamable HTTP transport, OAuth 2.1 with authorization code grant, and Dynamic Client Registration) make it impractical to use existing open-source GitLab MCP servers, as they predominantly support stdio transport only.

Request:
- Is there a planned timeline for an official GitLab MCP integration for Rovo Agents?

This integration would significantly enhance the value of Rovo for teams that rely on GitLab as their primary source control platform.

Thank you for your time and support.

[Ron Support_Votazz]

Hi V'yacheslav,

I can't speak for Atlassian's roadmap, but as of June 2026 there is no
announced GitLab MCP integration for Rovo. The MCP partner gallery includes
GitHub (and Atlassian's own Rovo MCP Server covers Bitbucket Cloud), but
GitLab is not on the list — and the Teamwork Graph connector you already
configured is indeed search/discovery only, as you found.

Your reading of the external MCP server requirements is exactly right. The
current Atlassian Administration documentation confirms: Streamable HTTP
transport ("SSE-only and stdio transports are not supported"), OAuth 2.1
authorization code flow with PKCE, Dynamic Client Registration (RFC 7591), and
a publicly accessible HTTPS endpoint:
https://support.atlassian.com/organization-administration/docs/add-an-external
-mcp-server-from-atlassian-administration/

That said, there are two practical paths for your use case right now:

1. GitLab's own official MCP server (worth piloting first). GitLab ships an
official remote MCP server, currently in Beta (introduced as an experiment in
18.3, Beta since 18.6, Premium/Ultimate tiers). It supports HTTP transport and
OAuth 2.0 Dynamic Client Registration, so on paper it matches Rovo's external
MCP requirements:
https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/
I haven't seen a confirmed report of someone registering it in Atlassian
Administration yet, so treat it as a pilot — but it's the closest thing to an
"official" integration available today. If you try it, sharing the result here
would help others.

2. A Forge app with a Rovo Agent + actions (fully supported, GA, works today).
Instead of MCP, you can define your agent in Forge using the rovo:agent
module and give it action modules — Forge functions that call the GitLab REST
API (/api/v4) directly. For your scenario that would be actions like
get-commits-by-author, list-merge-requests-by-date-range, get-pipeline-status,
each fetching from GitLab with gitlab.com declared under
permissions.external.fetch.backend. Both modules are GA, and this sidesteps
the MCP transport/OAuth/DCR requirements entirely while giving you precise,
programmatic API access.

- Rovo agent module: https://developer.atlassian.com/platform/forge/manifest-r
eference/modules/rovo-agent/
- Action module: https://developer.atlassian.com/platform/forge/manifest-refer
ence/modules/rovo-action/
- Egress permissions:
https://developer.atlassian.com/platform/forge/runtime-egress-permissions/
- Tutorial with the same pattern (Jira-focused): https://developer.atlassian.c
om/platform/forge/build-a-jira-issue-analyst-rovo-agent/

One caveat on the Forge route: a Rovo action can only handle up to 5 MB of
data, so for large result sets (e.g., all commits for a quarter) the action
should filter and aggregate server-side rather than return raw API payloads.

Given that you need structured queries (by author, by date range) rather than
generic GitLab browsing, the Forge route is arguably a better fit than a
generic MCP server anyway — you control exactly what the agent can ask for and
how the data is shaped for analysis.