Skip to main content
Glama
Sign In
librarian

librarian

by Nullislander0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fetch

Retrieves full document, thread, or passage content as clean markdown with citation metadata from a search-result ID, with configurable scope and output token budget.

Instructions

Full text of a result as clean markdown, with citation metadata.

Args: chunk_id: id from search results, e.g. "gis_se:a:12345#c0". scope: "chunk" (just that passage), "document" (the whole post or page, default), or "thread" (question plus replies: accepted answer, vendor staff, experts and top-voted first). max_tokens: approximate output budget (default 6000). Content beyond it is listed by id so you can fetch specific parts; raise it only when you need the whole thread.

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": {
      "chunk_id": "<chunk_id>"
    },
    "name": "fetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNodocument
chunk_idYes
max_tokensNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden and does real work: it discloses the default scope and token budget, the markdown-plus-citations output shape, and the truncation contract (content beyond the budget is listed by id so it can be fetched in pieces). It doesn't cover error behavior for an invalid chunk_id or rate/pagination limits, keeping it below 5.

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 front-loaded with the one-line purpose, then an Args block that keeps each parameter explanation to a line or two. Every sentence adds information an agent needs; the thread-scope sentence is slightly dense but justified given three distinct ordering rules.

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?

An output schema exists, so return values needn't be re-explained, and the description correctly limits itself to inputs and truncation behavior for a 3-parameter read tool. The remaining gap is minor: no mention of failure modes for a stale or malformed chunk_id.

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?

Schema description coverage is 0%, so this description must carry the parameters, and it does: chunk_id format is shown with a concrete example, scope enumerates all three valid values with what each returns and which is default, and max_tokens explains default and the consequence of exceeding it. The schema's bare string-typed 'scope' would otherwise leave an agent guessing.

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 first sentence states a specific verb and resource: retrieve the full text of a result as clean markdown plus citation metadata. That clearly distinguishes it from 'search' (which returns results, not content) and 'outline' (which returns structure). It does not explicitly name those siblings, so it stops short of a 5.

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 usable selection guidance: chunk_id comes 'from search results', scope chooses chunk vs document vs thread, and max_tokens should be raised 'only when you need the whole thread'. What's missing is any statement of when not to use it or an explicit handoff from search/outline, so it is strong but not exhaustive.

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

Deploy Server

Other Tools