Skip to main content
Glama

read_file

Read text file contents by absolute path, URI, or workspace-relative path; stream specific line ranges, or search inside the file with literal or regex patterns.

Instructions

Read the text contents of a file (absolute path, file:// URI, or workspace-relative path). Use start_line/end_line to stream a slice of a large file. Each line is prefixed with a 1-based line number + tab (cat -n style) for exact range math; this gutter is display-only — strip the leading '\t' before reusing a line as an edit_file/find_replace old_string. Binary files are rejected; output is capped at 200 KiB (use line ranges on large files). The header carries the file's mtime (RFC3339Nano) and SHA-256 — pass them back as expected_mtime/expected_sha on edit_file for optimistic-concurrency checks. Pass pattern to search WITHIN the file instead of windowing: it returns each matching line with its 1-based line number (and optional context_lines), so an over-cap file stays searchable in one tool — literal text by default (smart-case: case-insensitive when all lowercase), Go RE2 regex when use_regex; output is bounded by max_matches (default 200) and labelled when truncated. Combine pattern with start_line/end_line to restrict the search to a line window; pattern with limit is rejected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of lines to return starting at the first line (Claude Code-style window; first line defaults to 1). Mutually exclusive with end_line. Not usable together with pattern (search mode) — use max_matches instead.
offsetNoFirst line to read, 1-based (Claude Code-style alias for start_line; start_line wins if both are given).
patternNoSearch the file for this pattern instead of returning a window: returns each matching line with its 1-based line number (and optional context), bounded output. Literal text by default; a regular expression when use_regex is true. The whole file is scanned line-by-line regardless of size, so an over-cap file stays searchable. Combine with start_line/end_line to restrict the search to that line window; not usable with limit.
end_lineNoLast line to return (1-based, inclusive). Omit to read to the end of the file.
file_pathNoAbsolute path, file:// URI, or workspace-relative path of the file to read.
use_regexNoTreat pattern as a Go RE2 regular expression. Default false — pattern is literal text. Only consulted when pattern is set.
start_lineNoFirst line to return (1-based, inclusive). Omit to start from the beginning.
max_matchesNoMaximum number of matching lines to return in search mode. Default 200. Output is truncated (and labelled) beyond this. Only consulted when pattern is set.
context_linesNoLines of context to show before and after each match (like rg -C). Default 0. Only consulted when pattern is set.
case_sensitiveNoForce case-sensitive matching for pattern. Default (omitted): smart-case — case-insensitive when pattern is all lowercase, case-sensitive otherwise. Pass false to force case-INSENSITIVE matching even for an uppercase pattern. Only consulted when pattern is set.
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals line-number prefixing (cat -n style), the display-only nature of the gutter, the 200 KiB output cap, binary file rejection, header metadata (mtime and SHA-256), smart-case behavior, and truncation labeling. This is exceptional transparency.

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?

The description is information-dense and well-structured, with each clause earning its place. It is somewhat long, but for a tool with 10 parameters and complex behaviors (windowing, search, metadata), the length is justified. It front-loads the core purpose before diving into details.

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?

Since there is no output schema, the description explains the return format (line-number prefixes, header with mtime and SHA-256), output limits (200 KiB, max_matches), truncation labeling, and error cases (binary rejection). It also covers the interplay between search and windowing, making it complete for a complex 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?

Despite 100% schema coverage, the description adds crucial semantics beyond the schema: it explains how to strip the gutter before reuse, the mutual exclusivity of limit and pattern, offset as an alias for start_line, and how to pass expected_mtime/expected_sha on edit_file for concurrency checks. These details reduce misuse risk.

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 'Read the text contents of a file' — a specific verb and resource — and enumerates the accepted path forms. It clearly distinguishes itself from siblings by noting 'search WITHIN the file' (contrasting with search_in_files) and focuses on a single file (contrasting with read_multiple_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?

The description provides explicit situational guidance: 'Use start_line/end_line to stream a slice of a large file,' 'Pass pattern to search WITHIN the file instead of windowing,' and warns that 'pattern with limit is rejected.' It also states that binary files are rejected, giving a clear exclusion criterion.

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/plumbkit/plumb'

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