Skip to main content
Glama

source_text

Read-onlyIdempotent

Extract visible text from web snapshots by URL or hash; use grep for contextual matches. Copy exact quotes and link them to the snapshot URL to verify claims against primary evidence.

Instructions

Visible text of a snapshot (URL or sha256 prefix). With grep, only the matches with context (the first few, overlapping ones merged; prefer grep to reading the whole page). Copy quotes from here character for character, put them in quotation marks “…” or «…», and link the snapshot's URL right after the quote in the same sentence.

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": {
      "ref": "<ref>"
    },
    "name": "source_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
refYesthe snapshot: its URL, or a prefix of its sha256
grepNoa regular expression: only the matches, each with context
storeNosnapshot store (default $VERBATIM_STORE or ./.verbatim)
offsetNowithout grep, where in the text to start (next_offset continues a long page)
contextNowith grep, characters of text kept on each side of a match
max_charsNowith grep, characters of passages in all
max_matchesNowith grep, passages shown at most (matches_total says how many there were)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.0.8
    • addedInput schema / properties / max_chars
      Added value: +{
      +  "default": 4000,
      +  "description": "with grep, characters of passages in all",
      +  "type": "integer"
      +}
    • addedInput schema / properties / max_matches
      Added value: +{
      +  "default": 8,
      +  "description": "with grep, passages shown at most (matches_total says how many there were)",
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "without grep, where in the text to start (next_offset continues a long page)",
      +  "type": "integer"
      +}
  2. Changed4 schema fields changedv2.0.0
    • addedInput schema / properties / context / description
      Added value: +"with grep, characters of text kept on each side of a match"
    • addedInput schema / properties / grep / description
      Added value: +"a regular expression: only the matches, each with context"
    • addedInput schema / properties / ref / description
      Added value: +"the snapshot: its URL, or a prefix of its sha256"
    • addedInput schema / properties / store / description
      Added value: +"snapshot store (default $VERBATIM_STORE or ./.verbatim)"
  3. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavior beyond them: in grep mode only matches are returned, only the first few, with overlapping passages merged, and it conveys the quote-citation convention. Minor gap: truncation behavior (max_chars) and offset pagination are left to the schema.

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?

Front-loaded with the purpose, then grep behavior, then the citation rule. Dense and largely waste-free, though the final sentence is a long run-on mixing quoting, character-exactness, and link placement.

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?

For a 7-parameter read tool with 100% schema coverage, annotations, and no output schema, the description covers what comes back and how to use it. The remaining details (store default, offset pagination, max_chars) are adequately handled by the schema.

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 baseline is 3. The description earns a step above by explaining the grep mode's output semantics (matches with context, first few, overlapping merged) and the `ref` addressing form, which meaningfully extends the terse schema strings.

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 states precisely what is returned: the visible text of a snapshot, addressable by URL or sha256 prefix. The verb is implied rather than stated (a read), and no sibling tool is named, so it's clear but not differentiated from `snap` or `summary`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a strong in-tool directive -- "prefer grep to reading the whole page" -- which tells the agent how to use the parameters efficiently. However, it says nothing about when to choose this tool over `summary` or `snap`, and offers no exclusions or prerequisites.

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