Skip to main content
Glama
Sign In
gitlab mcp

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_merge_request_diffs

Read-only

Retrieves the changes and diffs of a merge request by IID or source branch, with optional file exclusion and view filtering.

Instructions

Get the changes/diffs of a merge request (merge_request_iid or source_branch required). To find resources, use the matching list or search tool.

Input Schema

NameRequiredDescriptionDefault
viewNoDiff view type
jmespathNoOptional JMESPath expression filtering the JSON result before return.
project_idYesProject ID or URL-encoded path
source_branchNoSource branch name
merge_request_iidNoMerge request IID
excluded_file_patternsNoArray of regex patterns to exclude files from the diff results. Each pattern is a JavaScript-compatible regular expression that matches file paths to ignore. Examples: ["^vendor/", "^test/mocks/", "\.spec\.ts$", "package-lock\.json"]

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.22
    • changedInput schema / properties / merge_request_iid / description
      Previous value: -"The IID of a merge request"New value: +"Merge request IID"
    • changedInput schema / properties / project_id / description
      Previous value: -"Project ID or complete URL-encoded path to project"New value: +"Project ID or URL-encoded path"
  2. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  3. Addedv2.1.18
  4. Removedv2.1.14
  5. Addedv2.1.11
  6. Removedv2.1.10
  7. Changed3 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / excluded_file_patterns
      Added value: +{
+  "description": "Array of regex patterns to exclude files from the diff results. Each pattern is a JavaScript-compatible regular expression that matches file paths to ignore. Examples: [\"^vendor/\", \"^test/mocks/\", \"\\.spec\\.ts$\", \"package-lock\\.json\"]",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / required
      Added value: +[
+  "project_id"
+]
  8. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the useful constraint that one of merge_request_iid or source_branch must be supplied, but says nothing about pagination, diff size limits, or behavior of the excluded_file_patterns filtering.

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?

Two short sentences with the core action and the key required-input condition front-loaded. There is no padding, though the sibling-routing sentence is vague rather than pointed.

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?

With no output schema and six parameters, the description covers the essential invocation contract but omits the filtering and view options and does not clarify result shape or size. It is adequate but leaves gaps relative to the tool's surface area.

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 100%, so every parameter including view, jmespath, and excluded_file_patterns is already documented. The description only re-emphasizes the merge_request_iid/source_branch choice, adding marginal meaning beyond the schema, which fits the baseline 3.

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

Purpose4/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 ('Get the changes/diffs of a merge request') and clarifies the conditional requirement for merge_request_iid or source_branch. It does not, however, differentiate this tool from close siblings such as list_merge_request_diffs, get_merge_request_changed_files, or get_merge_request_file_diff, so an agent cannot distinguish them from the text alone.

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

Usage Guidelines3/5

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

'To find resources, use the matching list or search tool' provides only generic routing advice and implies discovery workflow, but it never names the specific alternative (e.g., list_merge_request_diffs) or says when this tool should be preferred for a single merge request.

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

Deploy Server

Other Tools