Skip to main content
Glama

expand_result

Fetch the rest of a truncated result by supplying its ref, offset, and limit to page through the data. This retrieves the remaining items that a previous bounded view referenced.

Instructions

Fetch more of a result a previous tool showed you only a window of. Tools on this surface truncate the VIEW, never the DATA: when one prints a ref together with shown and total, the full result is held behind that ref and this is how you read the rest of it. Pass the ref plus offset and limit to page through it. Refs live in this server process only — they expire after 30 minutes and only the most recent handful are kept, so re-run the producing tool rather than storing a ref across sessions. A result that carried a secret is never retained and never has a ref, so nothing here can hand one back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refYesThe opaque handle a tool printed alongside its bounded view (res_ followed by 16 hex). Refs are per-process and short-lived — do not store one across sessions.
limitNoHow many items to return, 100 by default and at most 1000. The window stays bounded even when expanded — page with offset rather than asking for everything at once.
offsetNoIndex of the first item to return. Defaults to 0. Page by adding the previous window's shown count.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNo
kindNo
errorNo
itemsNo
shownNo
totalNo
offsetNo
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present, the description carries the full disclosure burden. It explains that refs are process-local, expire after 30 minutes, only the most recent few are kept, and secret-carrying results are never retained or given refs. This is substantial behavioral context beyond a generic 'fetch' statement.

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?

The core purpose is front-loaded in the first sentence, and each subsequent sentence earns its place by explaining ref lifecycle, paging behavior, or security guarantees. There is no filler or repetition.

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?

Given a fully documented schema and an output schema, the description supplies the missing operational context: where refs come from, how long they live, how to page through results, and which results cannot be accessed this way. An agent has everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all three parameters at 100% coverage, including ref format, expiry, limit bounds, and offset paging. The description reinforces the interaction ('Pass the ref plus offset and limit to page through it') but adds little meaning beyond what the structured schema already provides.

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 opens with a precise verb and resource: 'Fetch more of a result a previous tool showed you only a window of.' This clearly identifies the tool as the pagination entry point and differentiates it from the unrelated sibling tools like up, deploy, and status.

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 an explicit triggering condition: when a tool prints a ref together with shown and total counts, this is how to read the rest. It also provides a when-not: do not store refs across sessions; re-run the producing tool instead. It even excludes secret-bearing results from having refs.

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