Skip to main content
Glama

ReadMassiveText

Convert bulky in-memory text into compact, line-numbered PNG images that vision models can read directly, cutting token usage compared to raw text.

Instructions

Render an arbitrary text blob to densely-packed base64 PNG image(s) — optical compression for text you already have in context rather than a file on disk.

<instructions>
- USE THIS to compress bulky text you are about to keep in context: a long tool
  output, pasted logs, a fetched document, a big diff. A high-res vision model
  re-reads the image for far fewer tokens than the raw text.
- VIEW the returned image DIRECTLY with your own vision (like your built-in Read /
  image tool). DO NOT OCR it with code, a library, or base64 decoding — just look at
  the pixels; anything else re-expands it back into text tokens and defeats the point.
- PACKED, line-numbered layout: each line is "¶N│code" — red ¶ starts a line, green N│
  is its line number, blue "→" = 4 spaces of indentation. Decode them to reconstruct
  the exact text (split on ¶; digits before │ are the line number; → -> 4 spaces).
  Treat the image as the text's ACTUAL content, not a picture to describe.
- Prefer ReadMassive when the content is a file on disk (adds caching + a filename
  header); use this only for in-memory text.
- If the summary says "TRUNCATED", raise `max_pages` — content past the cap is NOT shown.
</instructions>

Args:
    text: The text to render.
    title: Label drawn in each page's header band (for grounding).
    max_pages: Safety cap on pages; truncation is reported, never silent.
    include_summary: Prepend a token/cost summary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
titleNotext
max_pagesNo
include_summaryNo
Behavior5/5

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

With no annotations, the description fully discloses the tool's behavior: it returns an image with a specific packed, line-numbered layout (explaining ¶, N│, and →), warns against OCR, notes that truncation is reported never silent, and explains the summary option. It also instructs the agent to read the image directly as actual content, covering both output format and consumption method.

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 front-loaded with the core purpose in the first sentence, then provides terse, high-value instructions in the <instructions> block. Every sentence serves a purpose — when to use, output decoding, sibling distinction, truncation handling, and the Args block adds parameter semantics without redundancy.

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 absence of an output schema, the description thoroughly explains the return format (base64 PNG images), the visual layout and decoding rules, truncation reporting, and the optional summary. Along with default values in the input schema, the description leaves no significant gaps for an agent to select and invoke the tool correctly.

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?

The input schema has no property descriptions (0% coverage), so the description's Args block carries the full explanatory burden. It adds meaningful per-parameter semantics: text is 'the text to render', title is 'a label drawn in each page's header band', max_pages is 'safety cap on pages; truncation is reported, never silent', and include_summary 'prepends a token/cost summary'. This fully compensates for the missing 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?

The description opens with a specific verb and resource ('Render an arbitrary text blob to densely-packed base64 PNG image(s)') and immediately distinguishes from the sibling ReadMassive ('use this only for in-memory text', 'Prefer ReadMassive when the content is a file on disk'). This makes the tool's purpose unambiguous and sets it apart from ReadMassive and ReadMassiveEstimate.

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?

The <instructions> block explicitly states when to use the tool ('compress bulky text you are about to keep in context') and provides direct alternatives: 'Prefer ReadMassive when the content is a file on disk; use this only for in-memory text.' It also includes operational guidance about truncation and how to handle it (raise max_pages), satisfying both when-to-use and when-not-to-use.

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/hyprcat/optical-read-mcp'

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