Skip to main content
Glama
Sign In
MCP-gitlab

MCP-gitlab

by sumirati
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Get Commit Details & Diff

get_commit
Read-onlyIdempotent

Retrieve detailed Git commit data by SHA—author, stats, modified files, and selective diffs. Filter by file and cap diff lines to inspect changes without exhausting context.

Instructions

Retrieve comprehensive details for a specific Git commit SHA, including author info, statistics, modified files, and selective unified file diffs. Use to inspect exact code changes made in a commit. Supports file_path filtering and line limits to prevent context exhaustion on large commits.

Input Schema

NameRequiredDescriptionDefault
shaYesCommit SHA or short commit hash to inspect
formatYesOutput format: 'markdown' (default) or 'json'markdown
file_pathNoFilter diffs to only this specific file (prevents token blowout on large multi-file commits)
with_diffYesIf true, includes file diffs for the commit
project_idYesProject numeric ID (e.g. 31) or namespace path (e.g. 'group/project-name'). URL-encoding is handled automatically.
max_diff_linesYesMaximum lines of diff text to return per file (default: 500)
ignore_lockfilesYesIf true, automatically collapses diffs for lockfiles and minified assets (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.1.0
    • addedInput schema / properties / format
      Added value: +{
+  "default": "markdown",
+  "description": "Output format: 'markdown' (default) or 'json'",
+  "enum": [
+    "json",
+    "markdown"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / ignore_lockfiles
      Added value: +{
+  "default": true,
+  "description": "If true, automatically collapses diffs for lockfiles and minified assets (default: true)",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "project_id",
-  "sha",
-  "with_diff",
-  "max_diff_lines"
-]New value: +[
+  "project_id",
+  "sha",
+  "with_diff",
+  "max_diff_lines",
+  "ignore_lockfiles",
+  "format"
+]
  2. First observedv2.0.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare the safe read-only, idempotent profile, so the description is free to add operational context instead: the warnings about context/token exhaustion on large commits and the mitigations (file_path filtering, line limits, lockfile collapsing) are genuine behavioral value. It does not mention auth requirements or pagination/truncation behavior in the response, keeping it below a 5.

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?

Three tight sentences: purpose plus return contents front-loaded, then usage, then the safety/mitigation constraint. No filler and nothing buried at the end.

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?

For a 7-parameter read tool with no output schema and full annotation coverage, the description covers the key risks (large diffs, token blowout) an agent needs before calling. It omits only minor operational detail such as result size ceilings or what happens when the SHA is not found.

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 (sha, format, file_path, with_diff, max_diff_lines, ignore_lockfiles) is already documented in the schema. The description restates the file_path filter and line-limit behavior but adds no syntax or format detail beyond what the schema says. Baseline 3 applies.

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 opens with a specific verb+resource ('Retrieve comprehensive details for a specific Git commit SHA') and enumerates what is returned (author info, statistics, modified files, unified diffs). The sibling tools (get_file_contents, get_project, gitlab_find_actions) occupy clearly different resources, though the description never names them to reinforce the distinction.

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?

'Use to inspect exact code changes made in a commit' gives a clear triggering context. It does not state when-not to use it or point to an alternative (e.g. get_file_contents for file-level history), so it stops short of full when/when-not guidance.

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