AgentFeed

Cascade history

get_cascade_history

Read-onlyIdempotent

Liquidation cascade history: past clustered same-side flush events reconstructed from our own tape, with start and end, prints, USD total and peak print, up to 72h back. /api/cascade tells you what is happening NOW; this tells you what already happened. Costs 0.03 USDC per call (x402, USDC on Solana or Base).

Input Schema

TableJSON Schema

Name	Required	Description
`gap_s`	No	max gap seconds within an event, default 60
`hours`	No	1-72, default 24
`scope`	No	symbol = just this symbol (default), all = every recorded USDT perp
`symbol`	No	USDT perp symbol e.g. SOLUSDT, BTCUSDT (default SOLUSDT)
`min_usd`	No	min event USD, default 100k (250k for scope=all)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	the get_cascade_history payload; a real captured example is free at https://x402.ochinimus.app/api/sample/get_cascade_history
`tool`	Yes	the tool that produced this payload

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 25, 2026

addedInput schema / properties / scope / description

Added value: +"symbol = just this symbol (default), all = every recorded USDT perp"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "additionalProperties": {},
+      "description": "the get_cascade_history payload; a real captured example is free at https://x402.ochinimus.app/api/sample/get_cascade_history",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "tool": {
+      "const": "get_cascade_history",
+      "description": "the tool that produced this payload",
+      "type": "string"
+    }
+  },
+  "required": [
+    "tool",
+    "data"
+  ],
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description's added value comes from disclosing the paid nature: 'Costs 0.03 USDC per call (x402, USDC on Solana or Base)' — critical operational knowledge an agent needs before invocation. It also adds the data-origin detail ('reconstructed from our own tape') and the 72h lookback cap, neither of which is in the structured fields.

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?

Three sentences with each earning its place: the first states purpose and output shape, the second provides the temporal contrast with the live endpoint, and the third discloses cost and payment rails. Critical payoff information (pricing, scope) is front-loaded early in the text.

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 a full output schema, 100% parameter coverage, and safety annotations, the description need not explain return shapes or idempotency. It covers purpose, data source, time bounds, cost, and the main alternative. The one gap is that it does not clarify how it differs from other historical liquidation tools in the sibling set, which is a plausible source of agent confusion.

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?

Schema description coverage is 100%, so every parameter (gap_s, hours, scope, symbol, min_usd) is already documented with defaults and examples in the schema. The description adds conceptual framing (clustered same-side flush events, peak print) that helps interpret gap_s and min_usd, but provides no per-parameter guidance beyond schema parity, matching the baseline of 3 for high coverage.

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 resource and operation: 'Liquidation cascade history: past clustered same-side flush events reconstructed from our own tape,' and specifies output contents (start/end, prints, USD total, peak print) and temporal bounds (up to 72h back). It also distinguishes itself from the live endpoint by contrasting 'what is happening NOW' with 'what already happened,' which separates it from real-time cascade tools.

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?

The description gives an explicit when/when-not: use /api/cascade for current activity and this tool for historical events. However, it only contrasts against one live endpoint and does not route among the many historical liquidation siblings (get_liq_history, get_recent_liquidations, get_cascade_scan), leaving some selection ambiguity in the broader sibling family.

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

All AgentFeed tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.