Skip to main content
Glama

mr_diff_sections

Group a merge request's diff by enclosing function or class instead of raw hunks, including every changed line. Reduces payload on large MRs without truncating mid-function.

Instructions

Fetch a merge request's diff grouped by enclosing function/class, not raw hunks.

AST-aware for new files (full tree-sitter chunking) and hunk-context-aware for modified files (declaration pattern + hunk-header hint). All changed lines (add/del) are always included — nothing dropped, only the framing changes. Prefer this over mr_diff_lines on a large MR (many files or a big diff) since grouping by symbol keeps the payload small without truncating mid-function.

Token-safe by construction, same guarantees as mr_diff_lines: on a large MR it returns a bounded page of files and lists the rest under "omitted_files" with "truncated": true. 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. include_context_lines: Include unchanged surrounding lines in each section. Default False keeps the payload small. 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. 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, title, author, branches, description, commits, diff_shas, files[{file_path, language, new_file, deleted_file, additions, deletions, sections[{symbol, symbol_type, start_line, end_line, changes}]}], truncated, omitted_files, skipped_files, stats}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
max_charsNo
skip_noiseNo
files_filterNo
include_context_linesNo
Behavior5/5

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

With no annotations, the description fully discloses behavior: it explains AST-aware vs hunk-context-aware processing, guarantees that all changed lines are included, and details token-safety mechanics (bounded pages, omitted_files, truncated). It also clarifies how parameters like skip_noise and max_chars are ignored in targeted fetches, adding significant behavioral context.

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 clear paragraphs and a compact Args/Returns format. Every sentence adds substantive information—purpose, differentiation, usage guidance, behavior, and parameter semantics—with no filler or redundancy.

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?

Given the tool's complexity (symbol grouping, multiple modes, safety guarantees) and absence of an output schema, the description provides a complete picture: it explains the algorithm, return structure, parameter behaviors, and fallback strategies. It is self-sufficient for an agent to invoke correctly.

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?

The input schema has zero descriptions, but the description's 'Args:' section thoroughly explains each of the 5 parameters, including defaults, edge cases (e.g., files_filter disabling noise-skip), and the meaning of include_context_lines. This fully compensates for the lack of schema descriptions.

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 'Fetch a merge request's diff grouped by enclosing function/class, not raw hunks,' which is a specific verb+resource+scope statement. It explicitly distinguishes itself from raw hunks and names a sibling tool (mr_diff_lines), making differentiation clear.

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?

It explicitly states when to prefer this tool over mr_diff_lines ('Prefer this over mr_diff_lines on a large MR...') and provides a workflow suggestion: 'For unknown-size MRs, call mr_changed_files first, then batch files_filter here.' It also describes the targeted fetch behavior for files_filter, giving clear use cases and alternatives.

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