reforge-mcp

Overview Schema Source Related Servers Discussions Admin

get_chunk

Read-onlyIdempotent

Reads an inclusive line range from a UTF-8 file without modifying it, so you can inspect findings or gather context for a patch. Returns source text and clamped line boundaries.

Instructions

Read an inclusive line range from a UTF-8 file without modifying it. Use when: you need to inspect a finding or obtain context for a patch. Don't use when: you need repository-wide findings (use scan_repo instead).

Returns {source, language, start_line, end_line, total_lines} on success, or {error} on failure. Source joins the selected lines with newlines; start_line/end_line report the clamped inclusive range. Large files can be read in slices; binary, lock and minified-file guards still apply.

Input Schema

Name	Required	Description
`end_line`	No	Last line, 1-indexed and inclusive; default null reads through EOF. An inverted range returns the start line; values beyond EOF clamp to EOF.
`file_path`	Yes	UTF-8 text file to read, e.g. /work/app/src/main.py. Relative paths resolve from the server working directory, not repo_root; the resolved file must remain inside repo_root. Binary/lock/minified files are skipped.
`repo_root`	No	Repository boundary used to validate file_path. Default null uses the server working directory; prefer an absolute path, e.g. /work/app.
`start_line`	No	First line, 1-indexed and inclusive; default 1. Values below 1 clamp to 1; a request beyond EOF returns the last line.

Output Schema

Name	Required	Description	Default
`error`	No
`source`	No
`end_line`	No
`language`	No
`start_line`	No
`total_lines`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.4.5Nov 6, 2026

addedInput schema / properties / end_line / description

Added value: +"Last line, 1-indexed and inclusive; default null reads through EOF. An inverted range returns the start line; values beyond EOF clamp to EOF."

addedInput schema / properties / file_path / description

Added value: +"UTF-8 text file to read, e.g. /work/app/src/main.py. Relative paths resolve from the server working directory, not repo_root; the resolved file must remain inside repo_root. Binary/lock/minified files are skipped."

addedInput schema / properties / repo_root / description

Added value: +"Repository boundary used to validate file_path. Default null uses the server working directory; prefer an absolute path, e.g. /work/app."

addedInput schema / properties / start_line / description

Added value: +"First line, 1-indexed and inclusive; default 1. Values below 1 clamp to 1; a request beyond EOF returns the last line."

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "end_line": {
+    "type": "integer"
+  },
+  "error": {
+    "type": "string"
+  },
+  "language": {
+    "type": "string"
+  },
+  "source": {
+    "type": "string"
+  },
+  "start_line": {
+    "type": "integer"
+  },
+  "total_lines": {
+    "type": "integer"
+  }
+}

Addedv0.2.9Oct 28, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that: binary/lock/minified guards still apply, large files can be sliced, and failure returns {error}. It does not reintroduce the safety hints redundantly.

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 purpose, then when/when-not, then return shape and guards — every block is scannable and largely earns its place. The explicit return-object breakdown is slightly redundant given an output schema exists, keeping it short of a 5.

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 read tool with full annotation and schema coverage plus an output schema, the description supplies the remaining behavior an agent needs: guards, slicing for large files, and the error case. The redundant return-shape sentence is the only mild over-explanation.

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 clamping and defaults are already documented per-parameter, and the description largely restates the clamping rule ('start_line/end_line report the clamped inclusive range'). The one genuinely additive note is that source joins lines with newlines, but overall it adds little beyond the schema.

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 specific verb and resource with scope: 'Read an inclusive line range from a UTF-8 file without modifying it.' The read-only, single-file, line-range framing immediately separates it from scan_repo, which is named directly.

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?

Uses explicit 'Use when' (inspect a finding, get context for a patch) and 'Don't use when' (repository-wide findings → scan_repo) clauses, naming the alternative sibling and the condition that selects it. Nothing is left to inference.

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

Deploy Server