Skip to main content
Glama

silica_read

Read-onlyIdempotent

Read a located file slice, heading section, or PDF page before citing it; returns outline, version, and truncation/next_start details so you can verify and continue.

Instructions

Read a located slice before citing it: lines start..end, one section by heading, a PDF page, or the whole file when it fits max_chars, always with the outline and a version; truncated and next_start say how to continue. A PDF is served from its own text layer, page by page: section="p. 8" serves one page — the whole page, ~1.2k tokens (measured 2026-09-09), so ask for it to cite a passage a search located, and widen the search's width to explore — pages counts them, page_map gives the pages the slice covers, and extract_path is that text on disk, for grep and the harness's own reader (a cache, rebuilt when the PDF changes, under no version guard). A PDF or office file with a .md extracted beside it is served from that instead, and source_state says whether the original still hashes to what the conversion recorded: stale means the PDF changed and the .md did not, unverifiable that the sidecar records no hash or its original is gone. Reading the .md itself, the path a search hit carries, reports the same source and source_state. Either way source names the original, and a PDF with no readable text layer is error.unconverted. Carry version forward as expect_version to be refused instead of reading different bytes under an old citation; version is the served text's, never the original's.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoLast line; 0 = to the end, under max_chars
pathYesRoot-relative file path (from silica_files or a search hit)
startNoFirst line, 1-based
sectionNoServe this heading's section instead (exact title or unique prefix)
max_charsNoCap on the served text
expect_versionNoRefuse with error.changed when the file's version differs

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive); the description adds far more: continuation via `truncated`/`next_start`, PDF page size (~1.2k tokens), extract_path as a cache rebuilt when the PDF changes and outside any `version` guard, `source_state` values (stale, unverifiable), and the `error.unconverted`/`error.changed` failure modes. This is unusually rich disclosure for a read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is well front-loaded, but the body is overstuffed: nested parentheticals, backticked tokens, dated measurements ("measured 2026-09-09"), and cache-internals details make it hard to parse for a read tool. Much earns its place, but the density and length cost readability.

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?

There is no output schema, so the description must describe returns, and it does: outline, version, truncated/next_start, pages, page_map, extract_path, source, and source_state, plus the error cases. For a read tool whose annotations already cover safety, nothing an agent needs to call it correctly is missing.

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 the terse per-parameter descriptions already carry the baseline. The prose adds real meaning beyond them: `section="p. 8"` serves one PDF page, `version` is the served text's and never the original's, and `expect_version` is the carry-forward guard that refuses rather than reading different bytes under an old citation.

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+resource ("Read a located slice before citing it") and enumerates the four serving modes: line range, heading section, PDF page, or whole file under max_chars. It distinguishes read from search by role ("a search located" vs. "widen the search's width to explore"), though it never names the sibling silica_search outright, leaving the routing slightly oblique.

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 states the core context clearly: use the read to pull the exact slice a search located so you can cite it, and points to search's `width` when you want to explore rather than cite. However there are no explicit exclusions or prerequisites (e.g., when to prefer silica_files), so it stops short of full when/when-not guidance.

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