Skip to main content
Glama

Read file contents

cat
Read-only

Read one or more files with line numbers, smart truncation, and git ref support. Returns structured output so agents can inspect code across multiple files in a single call.

Instructions

Read one or more files with line numbers and smart truncation. Returns structured output with metadata. Pass path for a single file, or paths to read several in one call (returns { files, count }) — collapsing what would otherwise be multiple round-trips. For large files, use startLine/endLine or maxLines to limit output. Use ref to read from a git branch/commit instead of disk (e.g. ref='main'). NOTE: reading with cat does NOT satisfy the built-in Edit/Write "must read first" guard (it tracks only the built-in Read tool) — run the built-in Read on a file immediately before editing it.

Input Schema

NameRequiredDescriptionDefault
refNoGit ref to read from (e.g. 'main', 'HEAD~1', a commit hash). When set, reads file content from git (git show ref:path) instead of disk.
pathNoPath to a single file
pathsNoRead multiple files in one call; a string or array. Returns { files, count }; a per-file failure is reported in that file's `error` and does not abort the others.
endLineNoStop reading at this line (inclusive)
maxLinesNoMax lines to return per file (default 200, use 0 for unlimited)
startLineNoStart reading from this line (1-based)
lineNumbersNoPrepend line numbers to each line (useful when locating a line). Does not register the file as read for the built-in Edit — use the built-in Read right before editing.

Output Schema

NameRequiredDescriptionDefault
pathNo
sizeNo
countNo
errorNo
filesNo
mtimeNoFile modification time (unix timestamp)
rangeNo
contentNo
retainedNo
truncatedNo
totalLinesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv5.0.1

TDQS

A4.9/5.0
Behavior5/5

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

Adds substantial context beyond the readOnlyHint annotation: default truncation at 200 lines, batched return shape { files, count }, per-file error isolation that does not abort the batch, git-backed reads via `ref`, and the non-obvious interaction with the Edit/Write 'must read first' guard.

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-loaded with the core action, then batched reads, then range limiting, then git ref, then the editing caveat — ordered by likely agent need. Every sentence carries distinct information; nothing is padding.

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?

For a 7-parameter read tool with an output schema and readOnlyHint, the description covers batching, truncation defaults, git sourcing, error behavior, and the edit-guard caveat. Nothing an agent needs 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 baseline is 3, but the description adds real value: it explains the path/paths dichotomy and the { files, count } result, gives a concrete ref example ('main'), and frames startLine/endLine/maxLines as the large-file strategy rather than just restating field names.

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 ('Read one or more files') and immediately names distinguishing features: line numbers, smart truncation, structured metadata. This clearly separates it from sibling directory/listing tools like ls, tree, and find_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?

Explicit routing guidance: use `path` for one file vs `paths` for batching, use startLine/endLine/maxLines for large files, and use `ref` to read from git instead of disk. It also gives a critical precondition — the built-in Read must be run before Edit/Write because cat does not satisfy that guard.

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