Skip to main content
Glama

view_file

Display a repository file with line numbers and paging controls so you can inspect specific sections of long files. Use start and end line parameters to read up to 200 lines per call.

Instructions

Show a file with line numbers, at most 200 lines per call. Use start_line/end_line to page through longer files; the header tells you the total number of lines. Paths are relative to the repository root. Errors if the file does not exist or the path leaves the repository.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "view_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
end_lineNo
start_lineNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does well: it discloses the 200-line truncation limit, that the header reports total line count, that paths are repo-root-relative, and that it errors on missing files and path traversal. Only the direction to the sibling tools for related work is missing.

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?

Three short, front-loaded sentences covering output format, pagination, and path/error semantics in that order. No filler.

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?

An output schema exists, so return values needn't be explained; the description still usefully describes the header and line cap. The main gap for a 3-param file reader is the missing guidance on picking this over siblings.

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 description coverage is 0%, so the description must compensate: it explains that start_line/end_line drive paging and that path is repository-root-relative. It does not explain defaults (start_line=1) or that end_line is optional/nullable, but the core semantics are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("Show a file") plus a distinctive output format (line numbers, 200-line cap). It doesn't name a sibling explicitly, but the read-only file-viewing purpose is unambiguous against str_replace, bash, and search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the paging workflow (use start_line/end_line) and the error conditions, which implies when to use it. But there is no explicit contrast with alternatives (e.g., use search to find a file, str_replace to edit), so the agent has to infer tool selection.

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

Deploy Server

Other Tools