Connecting Bitbucket to AWS DevOps Agent with the Atlassian Rovo MCP Server

Introduction

When an incident lines up with a recent deployment, AWS DevOps Agent can read commit history and code diffs from a connected repository to point at the likely change. That native integration supports GitHub, GitLab, and Azure DevOps. Bitbucket is not on that list at this time, so teams standardized on the Atlassian ecosystem lose commit-to-incident correlation exactly when they need it.

AWS DevOps Agent is extensible through the Model Context Protocol (MCP): you can connect a custom or remote MCP server and the agent discovers its tools and uses them during investigations (Connecting MCP Servers). Atlassian publishes a hosted Rovo MCP server that exposes Bitbucket (and Jira and Confluence). Registering it gives the agent read/search access to Bitbucket Cloud content it can bring into an incident investigation.

This article walks through the setup and shows the results.

Prerequisites

• AWS DevOps Agent enabled, with an Agent Space
• An Atlassian Cloud organization with admin access and the Bitbucket app (to trust the domain and approve the OAuth authorization)

Step 1: Trust the DevOps Agent domain in Atlassian

Before the DevOps Agent can communicate with the Atlassian Rovo MCP Server, you need to allowlist the AWS domain.

1. Navigate to the Atlassian admin console: https://admin.atlassian.com/
2. Click Rovo MCP server in the left navigation.
3. Click Add domain.
4. Add the callback domain: https://api.prod.cp.aidevops.<your-agent-space-aws-region>.api.aws/v1/register/mcpserver/callback. For example, if your agent space is in us-east-1: https://api.prod.cp.aidevops.us-east-1.api.aws/v1/register/mcpserver/callback

Step 2: Register the Rovo MCP server in AWS DevOps Agent

MCP servers register at the AWS account level and are shared across Agent Spaces.

1. Open the AWS DevOps Agent console and go to Capability Providers.
2. Find MCP Server under available providers and choose Register.
3. Enter:
   • Name: Rovo
   • Endpoint URL: https://mcp.atlassian.com/v2/mcp
   • Enable Dynamic Client Registration: select this checkbox.
4. Choose Next.

Step 3: Complete the OAuth authorization

On the authorization step, Rovo authenticates each user with a browser consent flow. With Dynamic Client Registration enabled, the agent registers with Rovo's authorization server automatically. Complete the browser consent, sign in to your Atlassian workspace, then submit. AWS DevOps Agent validates the connection.

Step 4: Add the MCP server to your Agent Space and allowlist read-only tools

1. In the console, select your Agent Space and open the Capabilities tab.
2. In the MCP Servers section, choose Add.
3. Select the registered Atlassian Rovo server.
4. Under Select MCP server tools, select discover and executeRead.

Why just these two? The Atlassian Rovo server doesn't expose each Bitbucket operation as its own individually-toggled tool. Instead it uses a two-tool pattern: discover finds the right operation by name from a natural-language description of your goal (for example, "list bitbucket pull requests"), and executeRead runs any read-only operation the server supports. By allowlisting only this pair, you give the agent the full read surface across Bitbucket while guaranteeing it cannot create, modify, or delete anything; the write and destructive dispatchers (executeWrite, executeDestructive) are simply never added. It's the least-privilege way to grant broad read access.

Once allowlisted, executeRead can invoke any of the following Bitbucket read operations:

Tool	Description
listBitbucketWorkspaces	Workspaces the user is a member of.
getBitbucketWorkspace	Get a workspace.
listBitbucketRepositories	Repositories in a workspace.
getBitbucketRepository	Get a repository.
getBitbucketRepoDefaultReviewers	The effective default reviewers for a repository.
getBitbucketRepoFileContent	Get file or directory content.
getBitbucketRepoBranch	Get a branch.
getBitbucketRepoCommit	Get a commit.
listBitbucketRepoCommitReports	List code-insights reports on a commit.
getBitbucketRepoCommitReport	Get a code-insights report on a commit.
getBitbucketRepoCommitReportAnnotations	The annotations of a commit report.
listBitbucketRepoPullRequests	List pull requests in a repository.
getBitbucketRepoPullRequest	Get a pull request.
getBitbucketRepoPullRequestDiff	The diff of a pull request.
listBitbucketRepoPullRequestComments	Comments on a pull request.
listBitbucketRepoPullRequestTasks	The tasks on a pull request.
listBitbucketRepoPipelines	Pipelines for a repository.
getBitbucketRepoPipeline	Get a pipeline.
listBitbucketRepoPipelineSteps	The steps of a pipeline.
getBitbucketRepoPipelineStep	Get a pipeline step.
getBitbucketRepoPipelineStepLog	The log of a pipeline step.
listBitbucketRepoDeployments	Deployments for a repository.
getBitbucketRepoDeployment	Get a deployment.
listBitbucketRepoEnvironments	Deployment environments for a repository.
getBitbucketRepoEnvironment	Get a deployment environment.

How the agent reads the repository

There is no code indexing or repository sync here. During an investigation, when the agent needs to see recent changes, it calls executeRead against the allowlisted Bitbucket operations to pull just what it needs; typically the recent commits on a branch, a specific commit, and that commit's diff. It reads that content on demand, then correlates it against the incident's timeline and telemetry. Nothing is copied or cached into the agent ahead of time.

Amplify the integration with a Skill

Registering the Rovo MCP server and allowlisting discover + executeRead makes the Bitbucket read surface available to the agent. It does not, on its own, tell the agent when to reach for it or how to drive the two-tool dispatch pattern. A skill closes that gap: it is where you instruct the DevOps Agent to use Rovo in a specific scenario.

For this integration, the skill tells the agent that when an investigation involves Bitbucket, checking a commit, branch, file, or pull request, it should reach the repository through the Rovo MCP association, and it spells out how:

• Run discover, then executeRead. It documents the two-step call: discover resolves the natural-language goal to an operation name, then executeRead runs that operation with its inputs, along with the parameter conventions that make each call succeed (always pass cloudId, for example).
• Fire at the right moment. The agent decides a skill is relevant from its description, so the description names the triggering scenario, checking Bitbucket repos, commits, branches, files, or pull requests, which is what pulls the skill into context mid-investigation.

Here is the shape of such a skill (redacted, illustrative):

---
name: bitbucket-atlassian-mcp
description: Query Bitbucket repositories, commits, branches, files, and pull
  requests through the "bitbucket" MCP association, which connects to Atlassian's
  Rovo MCP server (not a native Bitbucket API). Use when the investigation
  involves checking Bitbucket repos, commits, branches, files, or pull requests.
---

# Bitbucket via the Atlassian Rovo MCP association

The "bitbucket" association routes to Atlassian's Rovo MCP endpoint, not a
dedicated Bitbucket API. Repository operations are not pre-loaded as named
tools; discover them, then run them with executeRead.

## Discovery and invocation

1. Call `discover` with a natural-language goal ("list bitbucket repositories",
   "get pull request diff"). It returns the exact operation name and required
   inputs.
2. Call `executeRead` with:
   - `cloudId`: always pass it explicitly, even for operations that seem not to
     need it. Omitting it can cause a spurious "Failed to fetch cloud ID" error.
   - `name`: the exact operation name from discover (e.g. `getBitbucketRepoCommit`).
   - `inputs`: a flat object of the operation's parameters.

## Correlating a commit to an incident

1. `getBitbucketRepoBranch` (branch `main`) to get the tip commit and its parent.
2. `getBitbucketRepoCommit` on the hash for author, message, date, parent(s).
3. `getBitbucketRepoFileContent` at the exact file path for both the commit and
   its parent ref, then diff the two to isolate the change.

## Gotcha

`getBitbucketRepoFileContent` at the repository root (no `path`, or `/`) returns
404 even when files exist; always target an exact file path.

The MCP registration grants the capability; the skill is what reliably drives the agent to use it in the moment that matters.

Worked example: correlating an incident to a Bitbucket commit

With the read-only Bitbucket tools allowlisted, the agent can reach into Bitbucket during an investigation and tie a live incident back to the exact code change that caused it. Here is a real investigation from a demo environment.

The application began returning HTTP 500 on every GET / request, and a CloudWatch 5xx alarm opened an investigation. The agent read the recent commit history and a specific commit's diff from the connected Bitbucket repository and produced this root cause:

A code change reintroduced an active fault

The most recent pull request made a single-line change to app/app.py; it uncommented a fault-injection line so that every GET / request raises an unhandled exception and returns HTTP 500. The /health endpoint is on a different path and was unaffected, so container health checks kept passing and the task stayed registered as healthy; the failure surfaced only when real traffic hit the root route.

The diff the agent pulled from Bitbucket, which pinned the cause to one line:

--- a/app/app.py
+++ b/app/app.py
@@ -30,7 +30,7 @@ def get_products():

 @app.route("/")
 def index():
-#    raise Exception("Breaking change deployed - triggering DevOps alert")
+    raise Exception("Breaking change deployed - triggering DevOps alert")
     products = get_products()
     return render_template("index.html", products=products)

The agent confirmed this was the only change in the pull request, and that the parent commit had the same line commented out (the working state). It then tied the change to the deployment: the commit shipped as an ECS task definition revision through the pipeline, the change was latent through a low-traffic period because the health-check path never exercised the root route, and a later burst of requests exposed it. In our testing the whole investigation, from alarm to root cause with the offending line quoted, ran in about ten minutes.

How the investigation runs

The agent did not read Bitbucket in isolation; it correlated two independent sources. It fanned out parallel look-ups across the deployment history, container and load-balancer metrics, application logs, and the audit trail to establish what broke and when, then read the pull request diff and the parent file from Bitbucket to establish why. The Bitbucket commit read is the piece the Rovo MCP server provides; the deployment and telemetry come from the agent's native AWS access. It also ruled out alternatives explicitly (no container crash loop, no infrastructure change in the window, no resource pressure) before settling on the code change.

The key detail is that the agent didn't just point at the deployment; it read the commit and its parent from Bitbucket, saw exactly which line changed, and quoted it. That commit-to-incident correlation is the whole point of the integration, and it is exactly what the native GitHub/GitLab path provides for those providers.

Limits and scope

• Read access, not native code indexing. This pattern gives the agent read/search access to Bitbucket Cloud content during investigations. It is not native repository code indexing and it is not PR-triggered release-readiness review (that remains GitHub/GitLab only).
• Least-privilege by design. Allowlisting discover + executeRead grants the full read surface with no write capability. Do not add executeWrite or executeDestructive for an investigation-only integration.

Additional reading

For a different Bitbucket pattern, one that recreates AWS DevOps Agent's PR-triggered release-readiness review for Bitbucket through a custom AgentCore Gateway and Lambda bridge, see Bridging Bitbucket to AWS DevOps Agent's Release Readiness Review: A Custom AgentCore Gateway Pattern.

References

1. AWS DevOps Agent Skills. https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html
2. Get started with the Atlassian Remote MCP Server. https://support.atlassian.com/atlassian-ai-gateway/docs/get-started-with-the-atlassian-remote-mcp-server/
3. Atlassian Remote MCP Server supported tools. https://support.atlassian.com/atlassian-ai-gateway/docs/supported-tools/