Skip to main content
Glama

get_result_page

Read-onlyIdempotent

Retrieve the next page of a large Plex result using its result_id, with offset, limit, fields, match, and path to narrow items without refetching.

Instructions

Read more of a result that was too large to return in one piece.

Any tool whose answer is too large returns its first page with a paging block. Pass that block's result_id here. Nothing is fetched again: the stored result is paged, filtered and narrowed.

Args: result_id: From the paging block of the earlier answer. offset: First item to return, usually the previous next_offset. limit: At most this many items. Fewer come back if they would not fit. fields: Only these keys of each item. Dots reach nested keys, such as "statistics.sizeOnDisk". The paging.fields list shows what exists. match: Keep only items whose field contains this text, ignoring case, for example {"title": "alien", "year": "1979"}. path: Which list to page when the result holds several, as named in paging.lists. Defaults to the largest.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
limitNo
matchNo
fieldsNo
offsetNo
result_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

The annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: nothing is re-fetched or re-executed, the stored result is paged/filtered/narrowed in place, which reassures the agent this is a cheap, safe re-read.

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?

Purpose is front-loaded in the first sentence, then the usage mechanism, then a per-argument block. Every line carries information (syntax, defaults, examples) with no filler.

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?

With six parameters, zero schema description coverage, and an output schema that already documents return shape, the description supplies everything the agent needs: provenance of result_id, semantics of each optional filter, and the no-refetch behavior. Nothing material is missing.

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 the description carries the full burden and does so thoroughly: it explains result_id provenance, offset meaning (usually the prior next_offset), limit behavior (may return fewer), fields with dotted-path syntax and an example, match with case-insensitivity and an example, and path defaulting to the largest list. This is exactly the compensation required.

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 — reading another page of a previously returned oversized result — and explains the mechanism concisely in the first sentence. No sibling tool in this API surface does anything similar, so distinctiveness is inherent.

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?

Explicitly states when to call it: when an earlier answer was too large and returned a `paging` block, pass that block's `result_id`. There is no meaningful alternative to route between and no when-not guidance, which keeps this just short of a 5.

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