Skip to main content
Glama
Sign In
fs-mcp-server

fs-mcp-server

by qsrahman
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read File

read_file
Read-onlyIdempotent

Reads text files by line range using offset/limit, head, or tail; long files return a continuation offset after about 100,000 characters.

Instructions

Read a text file. Output is capped at about 100,000 characters; when a file is longer the result ends with the offset to continue from. Use offset and limit to read a range of lines, head for the first N lines, or tail for the last N lines (use only one of the three).

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": "read_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
headNoIf provided, returns only the first N lines of the file
pathYesAbsolute path, or relative to the server's working directory.
tailNoIf provided, returns only the last N lines of the file
limitNoMost lines to return, counting from offset.
offsetNoLine number to start reading from (1-based).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior the annotations cannot convey: an output cap near 100,000 characters and that truncated results end with the offset needed to continue. It omits error behavior (missing path, permission denied) and any encoding caveats.

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 sentences, zero filler: purpose first, then the truncation/continuation rule, then parameter routing. The most decision-relevant constraint (the mutual exclusion) is parenthetical and placed where it will be read alongside the alternatives.

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 single-required-parameter read tool with no output schema, the definition covers purpose, truncation semantics, and parameter routing adequately. Minor gaps remain around file-not-found/encoding behavior and confirming the return shape (line-numbered vs raw text), but nothing that would cause a misinvocation.

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 each of the five parameters is already documented, making the baseline 3. The description goes slightly beyond by imposing a cross-parameter mutual-exclusion constraint ('use only one of the three') that the schema cannot express, though it does not clarify interplay between offset and limit beyond what the schema states.

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 opens with a specific verb and resource ('Read a text file') and immediately scopes the resource to text, which implicitly excludes binary content. It does not explicitly contrast with the closest sibling, read_multiple_files, so an agent must infer the single-vs-multiple distinction from the names alone.

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

Usage Guidelines4/5

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

Clear operational guidance: use offset and limit for a line range, head for the first N lines, tail for the last N, and 'use only one of the three' resolves the ambiguous combination case. It stops short of stating when to prefer this over read_multiple_files or how to follow up after a truncated read beyond the offset hint.

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