Skip to main content
Glama

Read a Lore Library document

read_lore
Read-onlyIdempotent

Read one Lore Library document in full, a page at a time. A page of a long document ends with a cursor; passing that cursor returns the next page.

Input Schema

NameRequiredDescriptionDefault
cursorNo
document_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds genuinely new behavioral context: responses are paginated, a truncated page terminates with a cursor, and supplying that cursor yields the next page. It omits cursor expiry and not-found behavior, keeping it from a 5.

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

Conciseness5/5

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

Two tight sentences with zero filler. The core action is front-loaded and the pagination rule follows immediately as the only caveat that matters.

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?

No output schema exists, yet the description conveys the shape of a result (document content plus an optional trailing cursor) and implies that absence of a cursor means the document ended. It does not cover failure modes such as an invalid or expired cursor, which is the remaining gap for a 2-parameter read tool.

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 description coverage is 0%, so the description must carry parameter meaning. It explains the non-obvious 'cursor' parameter end-to-end (where it comes from and what passing it does), which is the only parameter needing explanation; 'document_id' is self-evident from 'Read one ... document' but is never stated explicitly.

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?

States a specific verb ('Read') and resource ('one Lore Library document in full'), and the phrase 'one ... document' implicitly contrasts with the sibling list_lore and search_lore tools. It stops short of naming those siblings, so an agent must infer the distinction.

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?

Usage is implied: fetch a single document by id, and pass a cursor to continue. There is no explicit statement of when to prefer this over search_lore or list_lore, nor any exclusion or prerequisite (e.g. needing a valid document_id from a prior list/search call).

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