gitlab-mcp

gitlab_mr_create

Create a GitLab merge request from a source branch into a target branch, with optional draft status, labels, assignee, and squash settings.

Instructions

Create a merge request from source_branch into target_branch. On 11.3 there is no reviewers attribute (assign instead) and no draft parameter: pass draft:true and the required "WIP: " title prefix is applied for you. Creating an MR whose branches already have an open one fails with 409 - update that one instead.

Input Schema

TableJSON Schema

Name	Required	Description
`draft`	No	mark as work in progress ("WIP: " title prefix)
`title`	Yes
`labels`	No	label names; a label that does not exist yet is created by GitLab when the caller has permission
`squash`	No	squash commits when this MR merges
`project`	Yes	project id ('42') or full path ('group/subgroup/app'); a path is URL-encoded for you
`assignee_id`	No	assignee numeric user id (find it with gitlab_users_search); 0 unassigns
`description`	No	GitLab Flavored Markdown
`milestone_id`	No	global milestone id, not the project-scoped iid
`source_branch`	Yes	branch name, e.g. feature/login
`target_branch`	Yes
`remove_source_branch`	No	remove the source branch when this MR merges

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`iid`	No	internal id - the number in !123
`sha`	No	HEAD of the source branch
`state`	No	opened / closed / locked / merged
`title`	No
`author`	No	user reference
`labels`	No
`web_url`	No
`assignee`	No	user reference
`milestone`	No
`project_id`	No
`description`	No
`merge_status`	No	'can_be_merged' / 'cannot_be_merged' / 'unchecked'. A merged merge request on 11.3 still reports can_be_merged, so read state first - merge_status alone is not a green light
`changes_count`	No	a string on 11.3, not a number
`has_conflicts`	No	not sent by 11.3; compare merge_status instead
`source_branch`	No
`target_branch`	No
`merge_commit_sha`	No
`user_notes_count`	No
`work_in_progress`	No	11.3 marks a draft MR this way; the title carries a "WIP: " prefix. Verified present on every one of 100 merge requests on the live instance

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false (mutation), so the description must carry the rest. It discloses a concrete failure mode (409 on duplicate open MR) and version quirks (11.3 lacks reviewers/draft handling), which is real behavioral value beyond the annotation. Auth requirements and rate limits are not covered.

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?

Purpose is front-loaded in the first sentence, followed by caveats and the error case. Three sentences, each earning its place, though the version-specific detail is somewhat dense.

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

Completeness4/5

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

An output schema exists, so return values needn't be explained. For an 11-parameter mutation tool the description covers purpose, the key failure mode, and version caveats adequately; only minor gaps (permission/auth context) remain.

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 82%, so the schema already documents most parameters. The description's draft note ('pass draft:true and the required WIP: title prefix is applied') largely restates the schema's own draft description rather than adding new syntax or constraints, so the baseline 3 applies.

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?

States a specific verb and resource ('Create a merge request') and the exact scope ('from source_branch into target_branch'). The 409 sentence implicitly routes the agent to gitlab_mr_update, distinguishing it from read/update siblings.

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?

Gives a clear when-not ('creating an MR whose branches already have an open one fails with 409') and the alternative action ('update that one instead'), plus version-specific guidance for 11.3. It stops short of naming the sibling tool explicitly or covering general preconditions, so not a full 5.

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