gitlab-ci-mcp

Overview Schema Source Related Servers Discussions Admin

gitlab_create_merge_request

Creates a GitLab merge request from a source branch into a target branch in a specified project; check existing requests first to avoid duplicates.

Instructions

Create a merge request from source_branch into target_branch.

Not idempotent: creates a new MR each call. Check existing MRs first via gitlab_list_merge_requests if you want to avoid duplicates.

Examples: - "Open an MR from feature/login to master" → source_branch='feature/login' - "Open a WIP MR with a label" → title='Draft: ...', labels=['wip'] - Don't use to merge an already-open MR — use gitlab_merge_mr.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source_branch": "<source_branch>",
      "project_path": "<project_path>"
    },
    "name": "gitlab_create_merge_request"
  }
}

Input Schema

Name	Required	Description	Default
`title`	No	MR title. Auto-generated if omitted.
`labels`	No	Labels to apply.
`description`	No	MR description (markdown supported).
`project_path`	Yes	GitLab project path (e.g. 'my-org/my-repo'). Required by default. For legacy deployments only, set GITLAB_ALLOW_DEFAULT_PROJECT=true to use GITLAB_PROJECT_PATH when omitted.
`source_branch`	Yes	Source branch.
`target_branch`	No	Target branch (default 'master').	master
`remove_source_branch`	No	Delete source branch after merge.

Output Schema

Name	Required	Description	Default
`iid`	No
`hint`	No
`state`	No
`title`	No
`status`	No
`web_url`	No
`merge_status`	No
`has_conflicts`	No
`source_branch`	No
`target_branch`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.5.5Nov 5, 2026

removedInput schema / properties / project_path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / project_path / default
```
Removed value: -null
```

changedInput schema / properties / project_path / description

Previous value: -"GitLab project path (e.g. 'my-org/my-repo'). When omitted, the default from GITLAB_PROJECT_PATH env var is used."New value: +"GitLab project path (e.g. 'my-org/my-repo'). Required by default. For legacy deployments only, set GITLAB_ALLOW_DEFAULT_PROJECT=true to use GITLAB_PROJECT_PATH when omitted."

addedInput schema / properties / project_path / minLength
```
Added value: +1
```
addedInput schema / properties / project_path / type
```
Added value: +"string"
```

changedInput schema / required

Previous value: -[
-  "source_branch"
-]New value: +[
+  "source_branch",
+  "project_path"
+]

First observedv0.5.1Apr 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the description's 'not idempotent' note mostly reinforces structured data, though it adds the practical mitigation (list MRs first). It also shows how to produce WIP/draft MRs via title/labels. The gap is that remove_source_branch defaults to true, meaning the source branch is deleted after merge, and nothing in the description warns about that consequence.

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

Conciseness5/5

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

Front-loaded with the core action, followed by the idempotency caveat and a short example block. Every sentence and example carries distinct information — creation semantics, duplicate avoidance, and the nearest sibling's boundary — with no filler.

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-value detail is unnecessary, and annotations cover the safety profile for this mutation. What is missing is permission/access requirements and any mention that the default remove_source_branch=true deletes the branch after merge, which matters for an agent deciding how to call it.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by mapping concrete intents to parameters, e.g. 'feature/login' -> source_branch and 'Draft: ...' plus labels=['wip'] for a WIP MR. It does not explain target_branch or remove_source_branch beyond what the schema already says.

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 first sentence states a specific verb and resource plus the exact branch semantics: 'Create a merge request from source_branch into target_branch.' The closing line explicitly distinguishes it from gitlab_merge_mr and the non-idempotency note points to gitlab_list_merge_requests, so an agent can separate it from siblings without reading schemas.

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

Usage Guidelines5/5

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

It gives both a when-to-use rationale (create new MRs; check existing ones first via gitlab_list_merge_requests to avoid duplicates) and an explicit when-not (do not use to merge an already-open MR — use gitlab_merge_mr). The natural-language examples further map user intents to the right invocation.

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