Skip to main content
Glama

Read a file's words

files_read_text
Read-onlyIdempotent

The words in a file as Conecto read them: text files, PDFs with a text layer, Word, Excel, PowerPoint, OpenDocument and HTML files, and scans once read with OCR (files_ocr). Up to max_chars from offset; next_offset gives the rest. status: read, reading (ask again in a minute), scan (an image or a PDF without text: files_ocr reads it), unpaid (auto-OCR could not be paid), none (no words to read) or failed. Free.

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": {
      "file_id": "<file_id>"
    },
    "name": "files_read_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
offsetNo
file_idYesThe file_id files_upload returned.
max_charsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description adds substantial detail: pagination behavior, statuses including reading/scan/unpaid/none/failed, supported formats, and that the operation is free.

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?

It is dense and front-loads the purpose before explaining pagination and status values. The status list is long but useful, though the description could be slightly more structured.

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?

Without an output schema, the description still conveys the essential return behavior via max_chars/offset/next_offset and status values. It is complete enough for correct invocation, though it could explicitly describe the returned text field.

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 low, but the description explains the otherwise undocumented offset and max_chars parameters as a pagination mechanism and notes that next_offset gives the rest. The file_id parameter is already documented in the schema.

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 title and description clearly identify the resource and action: reading the text content of a file. It names supported file types and distinguishes itself from files_ocr by noting that scans must be read with OCR first.

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?

It gives clear usage context for extraction and explicitly routes scanned files to files_ocr. It does not fully differentiate from every sibling such as files_get, but the primary alternative relevant to text extraction is named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources