Skip to main content
Glama
Preston-Harrison

Filesystem MCP Server

read_text_file

Read UTF-8 text file contents with optional line range selection to extract specific sections from files within allowed directories.

Instructions

Read the contents of a UTF-8 text file, optionally within a line range.

Args: path (str): File path to read (absolute or relative to allowed directories) fromLine (int, optional): Starting line number (1-indexed, inclusive) toLine (int, optional): Ending line number (1-indexed, inclusive)

Returns: str: File contents as text, or error message if failed

Note: - Path must be within allowed directory roots - Only reads UTF-8 text files (binary files will return error) - If line range specified, returns only those lines - Line numbers are 1-indexed

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
fromLineNo
toLineNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • main.py:285-317 (handler)
    The handler function for the 'read_text_file' MCP tool. It resolves the file path using _resolve, checks if it's a text file with _is_text, reads the content, applies optional line range slicing, and returns the content or an error message.
    @mcp.tool
    def read_text_file(
        path: str, fromLine: int | None = None, toLine: int | None = None
    ) -> str:
        """Read the contents of a UTF-8 text file, optionally within a line range.
    
        Args:
            path (str): File path to read (absolute or relative to allowed directories)
            fromLine (int, optional): Starting line number (1-indexed, inclusive)
            toLine (int, optional): Ending line number (1-indexed, inclusive)
    
        Returns:
            str: File contents as text, or error message if failed
    
        Note:
            - Path must be within allowed directory roots
            - Only reads UTF-8 text files (binary files will return error)
            - If line range specified, returns only those lines
            - Line numbers are 1-indexed
        """
        try:
            rp = _resolve(path)
            if not _is_text(rp):
                return f"Error reading file: '{rp}' is not a UTF-8 text file or is binary"
            lines = rp.read_text(encoding="utf-8").splitlines(keepends=False)
            if fromLine is None and toLine is None:
                return "\n".join(lines)
            start = (fromLine or 1) - 1
            end = toLine or len(lines)
            return "\n".join(lines[start:end])
        except Exception as e:
            return _human_error(e, "reading file")
Behavior4/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 effectively describes key traits: path restrictions ('within allowed directory roots'), file format limitations ('Only reads UTF-8 text files'), error handling ('error message if failed'), and line numbering specifics ('1-indexed, inclusive'). It doesn't cover aspects like performance, memory usage, or exact error formats, but provides substantial operational context.

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?

The description is efficiently structured with a clear opening sentence, followed by organized sections (Args, Returns, Note). Every sentence adds value: the first states core purpose, the Args section details parameters, Returns explains output, and Note lists critical constraints. No redundant or vague language is present.

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?

Given the tool's moderate complexity (3 parameters, no annotations, but with output schema), the description is complete enough. It covers purpose, parameters, return values, and key constraints (path restrictions, file format, line indexing). The output schema indicates a string return, and the description clarifies this includes error messages, providing full operational context without needing to explain low-level implementation details.

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?

Schema description coverage is 0%, so the description must fully compensate. It adds significant meaning beyond the bare schema: explains 'path' as 'absolute or relative to allowed directories', clarifies 'fromLine' and 'toLine' as optional, 1-indexed, inclusive line numbers, and ties parameters to functionality ('If line range specified, returns only those lines'). This transforms minimal schema into actionable understanding.

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 clearly states the specific action ('Read the contents of a UTF-8 text file') and resource ('text file'), distinguishing it from siblings like 'read_multiple_files' (single vs. multiple files) and 'grep' (search vs. direct reading). It explicitly mentions the optional line range feature, which further differentiates its functionality.

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?

The description provides clear context for when to use this tool (reading UTF-8 text files with optional line ranges) and implicitly suggests alternatives through sibling tool names (e.g., 'read_multiple_files' for batch operations, 'grep' for searching). However, it lacks explicit 'when-not-to-use' guidance, such as avoiding it for binary files or when needing to edit files (use 'edit_file' instead).

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/Preston-Harrison/fs-mcp-py'

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