gitlab-api

Accept merge request

gitlab_accept_merge_request

Idempotent

Merge a GitLab merge request immediately or set auto-merge to trigger once the pipeline succeeds, with options for squash and source branch removal.

Instructions

Accept (merge) a merge request.

Pass merge_when_pipeline_succeeds=True to set auto-merge (merge once the pipeline succeeds) rather than merging immediately. Optional body params: merge_commit_message, squash_commit_message, squash, should_remove_source_branch, sha.

Args: **kwargs: project_id and merge_request_iid (required) plus optional merge parameters listed above.

Returns: Response: A wrapper containing the original response and a MergeRequest model.

Raises: MissingParameterError: If the project_id or merge_request_iid is missing. ParameterError: If invalid parameters are provided.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gitlab_accept_merge_request"
  }
}

Input Schema

Name	Required	Description	Default
`data`	No
`name`	No
`group_id`	No
`user_ids`	No
`group_ids`	No
`rule_type`	No
`project_id`	No
`report_type`	No
`approval_rule_id`	No
`merge_request_iid`	No
`approvals_required`	No
`protected_branch_ids`	No
`applies_to_all_protected_branches`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv27.3.13Oct 25, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds merge-specific behavior: immediate merge vs auto-merge, optional source-branch removal and squash settings, the returned wrapper/model, and specific error cases, though it omits approval/permission prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and follows with the auto-merge rule, parameter list, return value, and errors. It is generally efficient, though the kwargs-style Args section is slightly awkward and some listed body parameters duplicate schema fields without added syntax.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and the input schema has 13 largely undocumented properties with 0% description coverage. The description covers the core merge operation, auto-merge, return wrapper, and error behavior, but it leaves relevant schema parameters unexplained and does not mention approval or permission prerequisites that matter for a merge action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It usefully names project_id, merge_request_iid, merge_when_pipeline_succeeds, and several merge body parameters, and clarifies that project_id and merge_request_iid are required despite the schema's zero required fields, but it does not explain many other schema properties such as group_id, user_ids, rule_type, report_type, approval_rule_id, approvals_required, or protected_branch_ids.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Accept (merge) a merge request.' It also distinguishes the action from related siblings such as approve_merge_request by clarifying that this actually performs the merge, including the auto-merge variant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear conditional usage rule: pass merge_when_pipeline_succeeds=True to set auto-merge rather than merging immediately. It does not explicitly compare against gitlab_approve_merge_request or gitlab_cancel_merge_when_pipeline_succeeds, but the main when-to-use distinction is present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server