> [!note] > This issue extends an existing MCP tool. Follow [Adding a new tool](https://docs.gitlab.com/development/duo_agent_platform/mcp/#adding-a-new-tool) guidance, including opening an MCP Tool Proposal for the `approve` and `unapprove` methods before implementation. ## Problem Statement / Use Case A customer gap analysis comparing the GitLab MCP server against the community `zereight/gitlab-mcp` server flagged **Approve MR** as a blocking gap: the community server ships `approve_merge_request`, the GitLab MCP server has no equivalent. Concrete use case: The customer's SAC team wants an agent that auto-approves a merge request once all required checks pass. Today there is no MCP tool that can perform an approval, so this flow is blocked end-to-end. The Anthropic integration additionally requires **unapprove** as a hard requirement (confirmed in https://gitlab.com/gitlab-org/gitlab/-/work_items/617967#note_3717912834), so both directions are in scope. ## Proposed Design `save_merge_request_review` (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249708, tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/605881) is a method-gated tool that dispatches on a `method` enum. Its current values are `create_note`, `reply_discussion`, `create_diff_note`, `resolve_discussion`, `submit_review`, and (EE-only) `post_duo_review`. Add `approve` as a new enum value, dispatched the same way `post_duo_review` already is: a Ruby-side branch in `perform_v0_1_0` calling `MergeRequests::ApprovalService` directly (`app/services/merge_requests/approval_service.rb`) — the same service the REST `POST .../approve` endpoint uses. `post_duo_review` is the existing precedent for a non-GraphQL method living in this otherwise GraphQL-backed tool. Add `unapprove` the same way: a branch calling `MergeRequests::RemoveApprovalService` (`app/services/merge_requests/remove_approval_service.rb`) — the same service behind REST `POST .../unapprove` (`lib/api/merge_request_approvals.rb`). This mirrors GitHub's model, where approval is a review-submission verdict rather than a separate merge-lifecycle action, which is also why it folds into the review tool instead of becoming a standalone tool. Not to be confused with the existing `verdict` parameter on `submit_review`: that is a cosmetic label prefixed to the summary note text and performs no approval. Keeping approval as an explicit `method` value (rather than overloading `verdict: "approve"` with a side effect) keeps a text label from silently gaining write power. **Safety:** add an optional `sha` parameter to `approve`, mirroring the REST endpoint's staleness guard. When `sha` is given and no longer matches the merge request's head SHA, the tool refuses to approve instead of silently approving stale content. A silent stale approval is a worse failure mode for an unattended agent than for a human clicking Approve in the UI, so the tool description should recommend agents always pass `sha` (typically the `diff_head_sha` already returned by `get_merge_request`), even though the parameter stays optional for parity with REST. The `sha` guard applies to `approve` only; `unapprove` mirrors REST in taking no `sha`, since removing an approval carries no stale-content risk. Authorization reuses the existing `:approve_merge_request` and `:unapprove_merge_request` permissions already enforced on the REST paths. ## Scope and Non-Goals - In scope: `approve` and `unapprove` methods, CE. - No new tool name. These are additive enum values on an already-shipped tool. - No EE work: unlike `post_duo_review`, neither approval nor unapproval has EE-specific behavior to override. ## Resources - Customer gap analysis and internal team discussion converged on folding approval into this tool rather than adding a standalone `approve_merge_request` tool. - Anthropic integration requirement for `unapprove`: https://gitlab.com/gitlab-org/gitlab/-/work_items/617967#note_3717912834 - Existing tool: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249708, tracked by https://gitlab.com/gitlab-org/gitlab/-/work_items/605881 - REST endpoints: `lib/api/merge_request_approvals.rb` (`POST /projects/:id/merge_requests/:merge_request_iid/approve` and `POST .../unapprove`) - Services: `app/services/merge_requests/approval_service.rb`, `app/services/merge_requests/remove_approval_service.rb` - MCP tool naming/consolidation conventions: https://docs.gitlab.com/development/duo_agent_platform/mcp/#tool-naming-and-consolidation-conventions - Companion issue: standalone `accept_merge_request` MCP tool (merge / auto-merge), filed alongside this one. ## Implementation Plan 1. Open an MCP Tool Proposal for the `approve` and `unapprove` methods and get it ratified. 1. Add `approve` and `unapprove` to the `method` enum in `app/services/mcp/tools/merge_requests/save_merge_request_review_service.rb` (`METHOD_PARAMS`, `input_schema.properties.method.enum`); `sha` is the only method-specific parameter, optional and valid for `approve` only. 1. Add a `perform_approve` branch in `perform_v0_1_0` that resolves the merge request, checks `sha` against `merge_request.diff_head_sha` when given, and calls `MergeRequests::ApprovalService`. 1. Add a `perform_unapprove` branch calling `MergeRequests::RemoveApprovalService`. 1. Specs: successful approval, sha-mismatch rejection, unauthorized user, already-approved idempotency; successful unapproval, unapproval without a prior approval, unauthorized user. 1. Update `doc/user/model_context_protocol/mcp_server_tools.md` (`save_merge_request_review` entry): add both methods to the parameter table and a `{{< history >}}` line.