Skip to main content
Glama
igordev96

gitlab-readonly-mcp

by igordev96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Find commits that changed a string

pickaxe
Read-only

Find when and by whom a piece of text was introduced by tracing commits whose diffs changed its occurrence count in GitLab history.

Instructions

Find the commits whose diff changed how often a piece of text appears — git log -S — so you can answer "when was this introduced, and by whom?". Each row is commit, date, author, subject, most recent first. The text is matched literally and case-insensitively, as search matches it, so a pickaxe never reports "nothing changed" about text the caller can see. Unlike search this walks the history of the ref and is therefore slower; pair it with search to go from "where is it" to "when did it appear". The ref defaults to the repository's default branch, and path is a git pathspec.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoBranch, tag, or commit whose history to walk. Defaults to the default branch.
pathNoA git pathspec to limit the search, e.g. 'src/components'.
limitNoMaximum commits to return (default 20).
queryYesExact text to follow through history, e.g. 'orderTotals'.
projectNoGitLab project path, e.g. 'group/subgroup/repo'. Defaults to GITLAB_DEFAULT_PROJECT.
case_sensitiveNoFollow the text case-sensitively. Default false: history is followed by case too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds matching semantics (literal, case-insensitive, consistent with `search`), the ref default (repository default branch), result ordering (most recent first), and the relative cost versus `search`. These are concrete behavioral traits beyond the structured fields.

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?

Front-loads the core behavior in the first clause, then layers return shape, matching semantics, cost/comparison to sibling, and argument defaults. Every sentence carries distinct information despite the length.

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?

With no output schema, the description still specifies the row shape (`commit`, `date`, `author`, subject) and ordering, so an agent knows what comes back. Combined with the annotations and full schema coverage, nothing needed to invoke it correctly is missing.

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; the description adds value by clarifying that matching is literal and case-insensitive consistent with `search`, which explains `case_sensitive`'s default behavior, and by restating ref/path semantics in workflow terms. It does not document `limit` or `project` beyond the schema, so it is not fully additive.

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: finding commits whose diff changed the occurrence count of a piece of text, with the git analogue (`git log -S`) and the user-facing question it answers. It explicitly distinguishes itself from the `search` sibling, so an agent can select between them without opening either schema.

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?

Gives explicit when-to-use and the routing rule: use `search` to find where text is, use this to find when it appeared, and pair them. It also warns that this walks history and is slower, which is exactly the exclusion criterion an agent needs.

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