gitlab-ci-mcp

Overview Schema Source Related Servers Discussions Admin

gitlab_get_merge_request_changes

Read-onlyIdempotent

Lists changed files and truncated diffs for a GitLab merge request to support code-review queries such as what changed in an MR; fetch full file content separately when needed.

Instructions

List changed files in a merge request with truncated diffs (2KB per file).

Useful for code-review-style queries ("what changed in !42?"). Diffs beyond 2KB are truncated — fetch the raw file via gitlab_get_file for full content.

Examples: - "What did MR !42 change" → mr_iid=42 - If you need full content of a changed file, use gitlab_get_file with the MR's source branch.

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": {
      "mr_iid": "<mr_iid>",
      "project_path": "<project_path>"
    },
    "name": "gitlab_get_merge_request_changes"
  }
}

Input Schema

Name	Required	Description	Default
`mr_iid`	Yes	Merge request IID.
`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.

Output Schema

Name	Required	Description	Default
`files`	Yes
`title`	Yes
`mr_iid`	Yes
`files_count`	Yes
`total_count`	Yes
`api_overflow`	Yes
`api_truncated`	Yes
`api_total_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 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: -[
-  "mr_iid"
-]New value: +[
+  "mr_iid",
+  "project_path"
+]

addedOutput schema / $defs / FileChange / properties / diff_truncated

Added value: +{
+  "title": "Diff Truncated",
+  "type": "boolean"
+}

changedOutput schema / $defs / FileChange / required

Previous value: -[
-  "old_path",
-  "new_path",
-  "new_file",
-  "renamed_file",
-  "deleted_file",
-  "diff"
-]New value: +[
+  "old_path",
+  "new_path",
+  "new_file",
+  "renamed_file",
+  "deleted_file",
+  "diff",
+  "diff_truncated"
+]

addedOutput schema / properties / api_overflow

Added value: +{
+  "title": "Api Overflow",
+  "type": "boolean"
+}

addedOutput schema / properties / api_total_count

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Api Total Count"
+}

addedOutput schema / properties / api_truncated

Added value: +{
+  "title": "Api Truncated",
+  "type": "boolean"
+}

addedOutput schema / properties / total_count

Added value: +{
+  "title": "Total Count",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "mr_iid",
-  "title",
-  "files_count",
-  "files"
-]New value: +[
+  "mr_iid",
+  "title",
+  "files_count",
+  "files",
+  "api_truncated",
+  "api_total_count",
+  "api_overflow",
+  "total_count"
+]

First observedv0.5.1Apr 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's real contribution is the output-shape caveat: diffs are truncated at 2KB per file. That is exactly the kind of lossy-result behavior an agent must know to avoid misreading a partial diff, and it supplies the recovery path (gitlab_get_file on the source branch).

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?

Front-loaded with the core behavior and truncation limit, then examples. Slight redundancy: the gitlab_get_file fallback is stated in prose and again in the example bullet, costing a few lines without adding new information.

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

Completeness5/5

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

A two-parameter read tool with an output schema; return values need not be described. Truncation, the recovery path, and usage context are all covered, leaving nothing an agent needs in order to call it correctly.

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 baseline is 3, but the example ('What did MR !42 change' → mr_iid=42) concretely maps the IID concept to the user-facing '!42' notation and clarifies the source-branch relationship used with gitlab_get_file.

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 opens with a specific verb+resource+scope: 'List changed files in a merge request with truncated diffs (2KB per file)'. That distinguishes it from gitlab_get_merge_request (metadata) and gitlab_get_file (single-file content) without the agent needing to open a schema.

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?

It gives a concrete usage context ('code-review-style queries'), a worked example ('What did MR !42 change' → mr_iid=42), and an explicit alternative for a sub-case (use gitlab_get_file with the source branch for full content). It does not explicitly contrast with gitlab_get_merge_request, but the when-to-use guidance is otherwise clear.

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