Skip to main content
Glama

get_documents

Read-onlyIdempotent

Retrieve full text of up to 50 documents by ID or virtual path in a single call. Returns each document under its own header and isolates read errors so one failure doesn't block the rest.

Instructions

Retrieve up to 50 documents' full text in one call, by ID or path, each under its own header in the order asked. A file that can't be read gets an error line and doesn't stop the others; past 2,000,000 characters in all, the rest get one too. Pair with list_files sort "newest" and limit to read the newest entries of a folder in two calls.

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": {
      "containerId": "<containerId>",
      "files": "<files>"
    },
    "name": "get_documents"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYesJSON array of document IDs (UUID) or virtual paths, e.g. ["/log/2026-11-08.md","id2"]. Max 50.
containerIdYesContainer ID or name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnly/idempotent annotations, it discloses partial-failure semantics (an unreadable file emits an error line without aborting the batch) and a hard aggregate budget of 2,000,000 characters, plus output ordering and per-document headers. That is exactly the behavioral context an agent cannot get from annotations.

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?

Three dense sentences, front-loaded with the core action and limits before the workflow tip. The phrase 'the rest get one too' is slightly elliptical but still decipherable from context.

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 two-parameter read tool with annotations and no output schema, the description covers capacity, error handling, ordering, and a companion workflow, leaving nothing an agent needs in order to invoke it correctly.

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 parameter list is already documented, but the description adds meaning the schema does not: results appear in the order requested, each under its own header, and the error-line behavior applies per entry. containerId receives no extra clarification.

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 ('Retrieve ... documents' full text') plus scope ('up to 50 ... in one call') and lookup modes ('by ID or path'). The batching scope implicitly but clearly separates it from the singular get_document sibling.

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?

Gives a concrete two-call workflow with list_files using sort "newest" and limit to read a folder's newest entries. It lacks an explicit exclusion such as 'use get_document for a single file', so it stops short of full when-not guidance.

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