Skip to content
Easy AI How-To

AdvancedAgentsBuilding

Read and write PR comments with the GitLab and Bitbucket MCP servers

Part of the Software Factory series, a pattern by Greg Alton. Review is the second-to-last station on the line. Here the factory reads the published pull request (called a merge request on GitLab), posts a structured review, fixes findings one at a time, and leaves a written disposition, all through MCP.

Time
About 30 minutes
Checked
Tools
GitLab MCP server, Atlassian Rovo MCP (Bitbucket Cloud)

If a button name on the screen does not match this guide, follow the action. These products rename buttons often. This is an advanced guide: it uses code, and each technical term is explained the first time it appears. Model names and prices change, so check the linked docs before you ship.

Steps

  1. Connect GitLab

    GitLab has a built-in MCP server at /api/v4/mcp on your GitLab instance (for GitLab.com, https://gitlab.com/api/v4/mcp). It signs in with OAuth on first use. A header can limit which toolsets the agent sees:

    {
  "mcpServers": {
    "gitlab": {
      "type": "http",
      "url": "https://gitlab.com/api/v4/mcp",
      "headers": { "X-Gitlab-Enabled-Mcp-Server-Toolsets": "core" }
    }
  }
}

    Useful tools include get_merge_request, get_merge_request_diffs, get_merge_request_notes, save_note, and save_merge_request_review. Check GitLab's tools page for the current toolset names.

  2. Connect Bitbucket Cloud

    Bitbucket Cloud tools come through the same Atlassian Rovo MCP server as Jira (https://mcp.atlassian.com/v2/mcp). The workspace must be linked to an Atlassian organization, and at launch the Bitbucket tools required API-token authentication (scopes read:bitbucket:agent-interface and write:bitbucket:agent-interface) enabled by an org admin. Check Atlassian's docs for the current auth options. Tools include pull request get, diff, comments, and add comment.

  3. Deny merge tools everywhere

    Both servers include a merge tool (accept_merge_request on GitLab, mergeBitbucketRepoPullRequest on Bitbucket). Block them in your MCP client's tool permissions so no agent can merge, whatever its prompt says. Give Git host tools only to the orchestrator (to open the PR after you approve) and the two review agents.

  4. Post one structured review

    ---
name: pr-code-reviewer
description: Reads a published PR/MR diff and posts ONE structured review comment. Never edits code.
model: opus
---
1. Resolve the PR/MR for the current branch. Read the complete diff
   and the tests that cover it. If you can't read it, stop.
2. Run the repo's checks and security scan. Never claim a pass you
   didn't run.
3. Post exactly one comment:
   ## Code Review   (findings with file:line, severity, why)
   ## Security Review
   ### Verification (commands + results)
Never modify files, commit, push, or merge.

  5. Fix one finding per cycle

    ---
name: pr-review-fixer
description: Triages the latest review and prepares ONE tested fix, then waits for approval.
model: opus
---
1. Read the live review comment. Sort every finding: Fix, Waive
   (with evidence), or Defer (with follow-up ticket).
2. Take the highest-severity Fix. If behavior changes, write a
   failing test first, then the minimal fix. Run tests.
3. STOP. Return "READY_FOR_APPROVAL: F1 — title", the diff summary,
   test results, and the proposed commit message.
4. Commit and push only after the developer approves this finding.
5. When no Fix items remain, post the Review Disposition Report.

  6. Post the Review Disposition Report

    Every review round ends with a durable comment on the PR that accounts for every finding:

    ## Review response — Accept / Partial / Reject
Follow-up to review comment <id>, verified on <branch> @ <sha>.

### Accept (fixed)
| Finding | Action |
| --- | --- |
| Missing input validation | Fixed. Added check + test. Commit abc123. |

### Partial (scoped / deferred)
| Finding | Response |
| --- | --- |
| _none_ | |

### Reject (incorrect or N/A)
| Finding | Counter |
| --- | --- |
| _none_ | |

### Verification
<exact commands and results>

Tips

  • Keep the review format identical on GitLab and Bitbucket. Only the tool calls differ.

  • If the MCP server is missing or unauthorized, the agent should stop and tell you, not fall back to tokens in shell commands.

  • Let the PR pipeline finish between fix cycles, then have the fixer re-read the live comments.

Common questions

Can I use GitHub instead?

Yes. GitHub has an official MCP server with similar PR tools. The review and disposition formats stay the same.

Why only one fix per cycle?

Small, separately approved commits are easy to review and easy to revert. Batching fixes hides mistakes.

Inline comments or one big comment?

The pattern uses one structured comment by default so it's easy to find and reference. Ask for inline comments when a finding is tied to a specific line.

More guides

Occasional notes

Hear when a new guide is up

A short note when a guide is added. No account, and no emails until this form is connected to a real list.

Placeholder. This form is not connected to an email service. Nothing you type is saved or sent.