Skip to main content
Glama

mr_diff_lines

Fetch a merge request's diff as line-numbered hunks with exact file paths and line numbers, safely bounded for large MRs, and optionally filter by files or lines.

Instructions

Fetch a merge request's diff as structured, line-numbered hunks.

Pure data, no LLM. Returns exact file paths, old/new line numbers, and diff content — everything needed to read a change precisely and to compute the diff positions required for inline comments.

Token-safe by construction: on a large MR it returns a bounded page of files and lists the rest under "omitted_files" with "truncated": true (never an oversized payload). Noise files (lockfiles, generated, binary) are listed under "skipped_files", not expanded. For unknown-size MRs, call mr_changed_files first, then batch files_filter here.

Args: url: Full GitLab merge request URL. files_filter: Optional list of file-path fragments to include. Passing this is a TARGETED fetch — noise-skip and the budget are disabled so you get exactly the files you ask for. lines_filter: Optional map of filename-fragment -> target new-file line numbers; returns compact line_mappings instead of full hunks. max_chars: Token-safety budget for the returned diff body (default 80000). Ignored for targeted fetches. skip_noise: Keep lockfiles/generated/binary out of the body (listed under skipped_files). Default True. Ignored when filtering.

Returns: {mr_number, ..., diff_shas, files[...], truncated, omitted_files, skipped_files, stats}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
max_charsNo
skip_noiseNo
files_filterNo
lines_filterNo
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses bounded pagination via 'omitted_files' and 'truncated', noise-file handling via 'skipped_files', and default budget behavior for max_chars/skip_noise. This is thorough and non-contradictory.

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 well-structured with a purpose sentence, behavioral guarantees, Args, and Returns. It is detailed but each sentence earns its place, front-loading the core purpose before diving into parameters.

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?

Even without an output schema, it lists the return object fields ({mr_number, ..., diff_shas, files[...], truncated, omitted_files, skipped_files, stats}) and explains the shape of line_mappings when lines_filter is used. This is complete for a complex diff tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the Args section adds rich meaning to all five parameters: url format, files_filter as a targeted-fetch trigger, lines_filter producing compact line_mappings, max_chars as a token-safety budget, and skip_noise for lockfiles/generated/binary.

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?

Description opens with a specific verb and resource: 'Fetch a merge request's diff as structured, line-numbered hunks.' It further clarifies exact file paths, old/new line numbers, and diff content, distinguishing it from sibling tools like mr_diff_sections and mr_changed_files.

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 guidance: 'For unknown-size MRs, call mr_changed_files first, then batch files_filter here.' It also explains when files_filter creates a targeted fetch and when max_chars/skip_noise are ignored, helping the agent choose the right mode.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SurajKGoyal/myopic'

If you have feedback or need assistance with the MCP directory API, please join our Discord server