Skip to main content
Glama

Ilu Rennik

Open an item in full

open
DestructiveIdempotent

Read inside a document: a deductible, what a policy covers, a claim's status. Use this when the answer is inside a document or fact find returned, such as a deductible, what a policy covers, a limit, a renewal date or whether a claim is paid. Do not use for locating something; that is find. Reads up to five items by the ids find returns. With look_for, a document returns only the passages that answer the question, by meaning and in any language, in one call: the way to answer what a policy, contract or statement says (a deductible, what is covered, a limit, a date). Without it, by the kind of id: a document's text in parts (offset, the answer's next_offset), or a fact with every receipt and what it replaced. A sealed fact opens to its name and dates only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "open"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoOne id from find, such as doc:51f0a9b7.
idsNoUp to five ids at once.
partNoWhich part of a long answer to read: the answer's `next_part`. Leave it out for the first.
offsetNoWhere to start reading a long document. The answer's next_offset.
look_forNoWhat to find inside the file, in the words of the question.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior2/5

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

The description frames the tool entirely as a read ('Read inside a document', 'Reads up to five items') and never mentions mutation, consumption of a seal, or anything irreversible, while the annotations declare readOnlyHint=false and destructiveHint=true. The only hint is 'A sealed fact opens to its name and dates only', which suggests seal-breaking but never states what is lost or that the operation is not read-only. Valuable return-shape detail is present (parts via `offset`/`next_offset`, fact receipts and replacements), but the core safety profile is contradicted rather than supplemented.

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 mode/routing information is front-loaded, but the same illustrative list ('a deductible, what a policy covers, a limit, a date') is repeated three times, and 'what a policy covers' / 'what is covered' restate each other. It reads as a single dense block without sentence-level separation of the two modes.

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?

With no output schema, the description carries the return-value burden and does so well: passages when `look_for` is used, document text in parts with `offset`/`next_offset` otherwise, facts with receipts and prior values, and the reduced payload for sealed facts. What is missing is the destructive consequence implied by the annotations, which is the one thing an agent could get wrong catastrophically.

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 baseline is 3, but the description adds genuine meaning beyond the schema: `look_for` searches 'by meaning and in any language' in one call, and `offset` is tied to continuation from the previous answer's `next_offset`. The choice between `id` and `ids` (up to five) and the `look_for` vs `offset` mode split are clarified in prose, not just in field 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 names a specific verb and resource — 'Read inside a document' and 'Reads up to five items by the ids `find` returns' — covering deductibles, coverage, limits, dates and claim status. It explicitly distinguishes itself from the sibling `find` ('Do not use for locating something; that is `find`'), so an agent can route between them without opening either schema.

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?

It gives both the when-to-use condition ('when the answer is inside a document or fact `find` returned') and the when-not-to-use condition with the named alternative (`find` for locating). It further decomposes usage into two modes — with `look_for` for question-answering passages, without it for raw text or fact receipts — which is the exact decision an agent must make before calling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources