Skip to main content
Glama
igordev96

gitlab-readonly-mcp

by igordev96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List commits at a ref

log
Read-only

List commits for a GitLab branch, tag, or commit newest first, with author, date, and subject. Filter by path and limit results without cloning into a working tree.

Instructions

List commits on a branch, tag, or commit — git log — newest first, without cloning it into a working tree. Each row is commit, date, author, subject, and a merge commit carries (merge). The ref defaults to the repository's default branch, is resolved before the walk, and the result states the commit it walked and synced_at. path is a git pathspec, so globs work — and history stops at a rename, because git's --follow accepts only one path and walks renames backwards; pass the new name or use get_commit when you need to see the rename itself. limit bounds the answer; when it hides older commits the result says so rather than inventing a total. Use get_commit on a row's full sha to see what it changed. Give either url — a GitLab /-/commits/<ref>[/<path>] link, e.g. 'https://gitlab.example.com/group/repo/-/commits/fix/PROJ-7608/src/index.tsx' — or ref and path; the link's host must be GITLAB_HOST.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoBranch, tag, or commit whose history to walk, e.g. 'fix/PROJ-7608'. Defaults to the default branch.
urlNoA GitLab history link, e.g. 'https://gitlab.example.com/group/repo/-/commits/develop'. Replaces ref and path; the host must be GITLAB_HOST.
pathNoA git pathspec to limit the walk, e.g. 'src/components/*.tsx'. History stops at a rename: a file's earlier names are not followed.
limitNoMaximum commits to return (default 20). A capped answer says so.
projectNoGitLab project path, e.g. 'group/subgroup/repo'. Defaults to GITLAB_DEFAULT_PROJECT.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.1

TDQS

A4.8/5.0
Behavior5/5

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

With readOnlyHint/openWorldHint already covering the safety profile, the description adds real behavioral context: no working-tree clone, ref resolution before the walk, the result reporting the walked commit and `synced_at`, truncation being disclosed rather than a fabricated total, and the rename termination behavior of `path`.

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 action and return shape, and every sentence carries information; the caustic details (rename stop, limit honesty) earn their place. It is dense, with several clauses packed per sentence, which slightly taxes readability but adds no filler.

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?

There is no output schema, so the description supplies the return shape itself (commit, date, author, subject, `(merge)` marker) plus the `synced_at`/walked-commit metadata. Combined with 100% parameter coverage, an agent has everything needed to invoke and interpret this tool.

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 goes further: it gives the concrete `/-/commits/<ref>[/<path>]` link shape with a full example for `url`, notes `url` replaces `ref` and `path`, and explains the glob/rename semantics of `path` and the capping behavior of `limit`.

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?

States a precise verb+resource ('List commits on a branch, tag, or commit'), names the git equivalent, and specifies ordering ('newest first') and the no-clone execution model. It is clearly distinguishable from siblings get_commit (what a single commit changed) and blame/list_tree.

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?

Explicitly routes to alternatives: 'Use `get_commit` on a row's full sha to see what it changed' and 'use `get_commit` when you need to see the rename itself.' It also states the two mutually exclusive input forms (either `url`, or `ref` and `path`) and their constraints.

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