gitlab mcp

get_file_blame

Read-only

Get git blame for a file at a given ref, mapping line ranges to the commit that last changed them. Limit the blame to specific lines with range_start and range_end.

Instructions

Get git blame for a file at a given ref. Each entry maps a contiguous range of source lines to the commit that last changed them (id, author, authored_date, message). Use range_start/range_end to limit blame to specific lines.

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": {
      "project_id": "<project_id>",
      "file_path": "<file_path>",
      "ref": "<ref>"
    },
    "name": "get_file_blame"
  }
}

Input Schema

Name	Required	Description
`ref`	Yes	The name of branch, tag or commit (required by GitLab blame API)
`jmespath`	No	Optional JMESPath expression filtering the JSON result before return.
`file_path`	Yes	The full path of the file to blame, relative to repo root
`range_end`	No	Last line of the blame range (inclusive, 1-based). Both range[start] and range[end] must be set together.
`project_id`	Yes	Project ID or complete URL-encoded path to project
`range_start`	No	First line of the blame range (inclusive, 1-based). Both range[start] and range[end] must be set together.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.1.66Sep 23, 2026

addedInput schema / properties / jmespath

Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}

Changed5 schema fields changedv2.1.62Sep 16, 2026
- addedInput schema / properties / range_end / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / range_end / minimum
```
Added value: +-9007199254740991
```
- addedInput schema / properties / range_start / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / range_start / minimum
```
Added value: +-9007199254740991
```
- changedInput schema / required
```
Previous value: -[
-  "file_path",
-  "ref"
-]New value: +[
+  "project_id",
+  "file_path",
+  "ref"
+]
```
Addedv2.1.45Jul 30, 2026
Removedv2.1.43Jul 26, 2026
Addedv2.1.18May 30, 2026
Removedv2.1.14May 22, 2026
Addedv2.1.13May 20, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description does not need to repeat safety semantics. It adds behavior beyond the annotations by explaining the entry structure: contiguous source-line ranges map to the commit with id, author, authored_date, and message. It does not cover pagination or edge cases, but the read-only hint plus output-shape context is meaningful.

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?

The description is two well-structured sentences. The first front-loads the action and resource; the second communicates the return shape and the optional range limitation. Every phrase contributes information, and there is no filler or duplication of schema text.

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?

Given there is no output schema, the description supplies the essential return semantics by naming the fields a caller can expect in each entry. The schema covers all parameters, and the read-only annotation covers the safety profile. Missing details such as pagination or behavior on nonexistent refs are minor for a straightforward blame call.

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 the schema itself documents all six parameters including range_start, range_end, ref, and file_path. The description adds only a light hint that range_start/range_end limit the blame to specific lines, which is useful but does not materially go beyond the schema. 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?

The description opens with a specific verb and resource: 'Get git blame for a file at a given ref.' This clearly separates it from read-content tools like get_file_contents and commit-history tools like get_commit-repository. It also states the central output concept (line ranges mapped to commits), removing ambiguity about what GitLab blame returns.

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 operational context: run blame at a specific ref dat and optionally constrain the result to a range of lines with range_start/range_end. It does not explicitly name sibling alternatives or say when not to use this tool, but 'git blame' is a distinct enough operation that the usage context is clear.

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