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

> Let the factory's review agents post a structured code and security review, fix findings one at a time, and record a disposition on GitLab or Bitbucket, never merging.

Level: Advanced
Tool: Agents
Category: Building
Time: About 30 minutes
Checked: 2026-10-15
Tools: [GitLab MCP server](https://docs.gitlab.com/user/model_context_protocol/mcp_server/), [Atlassian Rovo MCP (Bitbucket Cloud)](https://developer.atlassian.com/cloud/rovo-mcp/guides/supported-tools/)
HTML page: https://easyaihowtos.com/guides/software-factory-pr-comments-gitlab-bitbucket-mcp

**Part of the Software Factory series, a pattern by [Greg Alton](https://www.linkedin.com/in/greg-alton-ios).** 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.

## What you need

- A GitLab project or a Bitbucket Cloud repository
- The pr-code-reviewer and pr-review-fixer agents from part 3

## 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:
```json
{
  "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

```markdown
---
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

```markdown
---
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:
```markdown
## 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.

## FAQ

### 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.

---

This guide is from Easy AI How-To (https://easyaihowtos.com). It is independent of the tools named above. Screens and free-plan limits change, so check the date before you rely on a button name.