Skip to main content
Glama
Sign In
run402-mcp

run402-mcp

by kychee-com
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

expand_result

Retrieve the full result behind a truncated tool output ref. Pass the ref with offset and limit to page through data the view only partially showed.

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.

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": {
      "ref": "<ref>"
    },
    "name": "expand_result"
  }
}

Input 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

NameRequiredDescriptionDefault
refNo
kindNo
errorNo
itemsNo
shownNo
totalNo
offsetNo
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.126.1
    • addedOutput schema / properties / error / properties / diagnostics
      Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "column": {
+        "type": "integer"
+      },
+      "line": {
+        "type": "integer"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "line",
+      "column",
+      "code",
+      "message"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / error / properties / diagnostics_ref
      Added value: +{
+  "type": "string"
+}
    • addedOutput schema / properties / error / properties / diagnostics_total
      Added value: +{
+  "type": "integer"
+}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: ref lifetime (per-process, 30 minutes, most recent handful only), the guarantee that truncation is view-only, and a security-relevant exclusion (results carrying secrets are never retained and get no ref). Those are exactly the operational facts an agent could not infer from the schema.

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?

Four sentences, each front-loaded with its most important claim — what it does, why refs exist, how to page, then the expiry/secret caveats. No filler or restatement of the tool name.

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?

Output schema exists, so return shape needn't be described, and all three parameters are documented at 100% coverage. The remaining risk areas for a stateful handle-based tool — expiry, loss, and secret handling — are all addressed, leaving nothing an agent needs before calling it.

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; the description earns an extra point for explaining the paging model as a whole (ref plus offset and limit) and tying offset progression to the producing tool's shown count, which gives the parameters purpose rather than just types.

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 (fetch more) and resource (a previously windowed result), and explicitly frames the division of labor: tools truncate the VIEW, never the DATA. That framing makes it unmistakable against every sibling (deploy, run, status, etc.), none of which paginate.

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?

Gives the trigger condition precisely: 'when one prints a ref together with shown and total.' It also states the alternative for the failure case — re-run the producing tool rather than persisting a ref across sessions — so the agent knows both when to call this and when not to.

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