Skip to main content
Glama

read_file

Retrieves a file from the MemDrive memory library as text or an image preview, optionally including locally referenced Markdown images while keeping responses within size budgets.

Instructions

Read a file from the MemDrive memory library. TOTAL RESPONSE BUDGET — THREE LIMITS ON THREE DIFFERENT LAYERS. (1) HOST: the MCP host rejects a whole tool result over about 1 MB ("Tool result is too large. Maximum size is 1MB"), a host limit outside this server and separate from the model context window. (2) SERVER: text bytes plus base64 image bytes in one response must fit a single total budget — default 950,000 bytes, overridable with MEMDRIVE_RESPONSE_BUDGET_BYTES (clamped to 100,000–50,000,000). Text is guaranteed first; images share what remains and are downscaled in memory (trying higher JPEG quality before shrinking dimensions) or skipped with a note so a read never fails over an image and the file on disk is never modified. read_file returns a preview that fits the budget; to view the original image on disk, use open_image (only when the user asks). (3) MODEL: the model converts image pixels into tokens under its own limits, unrelated to the byte limits above. TWO-STEP READING — USE THIS WHENEVER A DOCUMENT REFERENCES SEVERAL IMAGES, OR ONE LARGE IMAGE: Step 1, call read_file with include_images=false to read the text and get the list of referenced image paths. Step 2, call read_file once per referenced image, passing that image path itself as path, so the image alone gets the whole response budget and keeps the best quality the budget allows. Reading an image file directly is also limited by the same total budget: a single image is returned untouched when it fits, and downscaled in memory only when the image itself exceeds the budget. Text files: returned as text (truncated at the smaller of the 1 MB text cap and the total budget, with a note when truncated). Markdown files: with include_images=true (the default), the text is returned TOGETHER WITH every locally-referenced image that fits the remaining budget in the same response — each image becomes an image content block, so the model sees words and pictures together. Remote (http) and data: images are skipped with a note. Images over the 3.5 MB preview cap are downscaled in memory only; the file on disk is never modified. Image files: returned as a single image content block (downscaled in memory only when over the preview cap or the total budget). If an image cannot be fitted within the budget at all, the result is text explaining that, not an error — the original is untouched. SVG files are returned as text (they are XML), never as image blocks. Paths are relative to the library root (MEMDRIVE_ROOT). Absolute paths are accepted only when they stay inside the root.

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
pathYesFile to read, relative to the library root (for example "notes/2026-10-28.md").
include_imagesNoFor Markdown files: true (default) returns the text together with its referenced images, within the total response budget; false returns text only plus the list of referenced image paths (step 1 of two-step reading). Ignored for non-Markdown files.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the 1 MB host limit, the configurable server budget, truncation and downscaling behavior, remote/data image skipping, SVG-as-text behavior, path-root restrictions, and that the file on disk is never modified.

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?

The description is front-loaded and organized into labeled sections for budget limits, two-step reading, and file types. It is somewhat long and repeats points such as downscaling in memory only and never modifying the file on disk, but the detail is mostly relevant for a complex tool.

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 read tool with no annotations and no output schema, the description covers the key layers of behavior an agent needs: host/server/model budget distinctions, Markdown and image handling, SVG handling, path constraints, and graceful failure behavior.

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 both parameters are already documented in the schema. The description adds meaningful behavioral context for include_images, especially the two-step reading workflow and budget allocation, and clarifies that absolute paths are accepted only inside the root; some overlap remains with the schema descriptions.

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: reading a file from the MemDrive memory library. It also explicitly distinguishes itself from open_image by saying open_image should be used to view the original image on disk only when the user asks.

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?

Gives explicit when-to-use guidance: use two-step reading whenever a document references several images or one large image, first with include_images=false and then per image path. It also names the alternative open_image and the condition for using it.

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