whale-data

Signal outcomes ledger

flag_outcomes

Read-onlyIdempotent

Recently fired signal-ledger flags with fire-time price and later price outcomes, logged live and never backfilled. For one signal type on one coin (how the last N played out) use signal_record.Descriptive market data only.

Input Schema

TableJSON Schema

Name	Required	Description
`coin`	No	Filter to one coin, for example BTC. A pair like ETH/USD works too, the quote leg is dropped. One symbol, not a list. Omit for every coin.
`pair`	No	Alias for coin.
`type`	No	Filter to one signal type. One of: whale-spike, funding-extreme, squeeze-flip, liq-cascade, flow-divergence, major-pctile, major-block, deriv-record. The underscore spellings used by alert rules (for example funding_extreme, or spike for whale-spike) are accepted too. Anything else is refused by name rather than answered as every signal. Omit for all types.
`hours`	No	How far back to look, in hours. Defaults to 48. Capped at 168 on the free plans and 720 on a paid plan; asking for more returns the cap, and the payload says so in `capped`. The all_time block is unaffected by this window.
`limit`	No	Max rows returned. Capped at 25 on the free plans and 500 on a paid plan; asking for more returns the cap, and the payload says so in `capped`.

Output Schema

TableJSON Schema

Name	Required	Description
`coin`	No	The coin filter applied, or null for all coins.
`note`	No	One line saying what the numbers cover, or why there are none. Read it before reporting any zero as a market reading.
`type`	No	The signal type filter applied, or null for all types.
`count`	No	How many rows this reply carries.
`hours`	No	The window actually read, in hours.
`capped`	No	Present only when an argument was cut down to a ceiling. Absent means nothing was clamped, so a smaller number than you asked for is the data and not a limit.
`signals`	No	The signals that fired in the window, each with its type, coin, fire time, price at fire time and later price outcomes where they have been scored.
`all_time`	No	Permanent counters from the archive, independent of the window asked for: fired, scored_h24, since, through and by_type.
`available`	No	False when this lane could not answer: a producer is dark, the pair sits outside this plan, or the argument named something we do not carry. Absent or true means the numbers are a real reading, not a guess.
`aggregates`	No	byType: how many fired per signal type inside the window.
`depth_note`	No	How far back the data behind this answer reaches.
`access_note`	No	What this connection could not return and what lifts it. Always pass this on to the user: it is the only place that information appears.
`valid_types`	No	The signal types that do exist, returned alongside unknown_type.
`unknown_type`	No	Set when the type asked for is not one this record keeps. Nothing was filtered and nothing was searched.
`total_in_window`	No	How many signals fired in the whole window, before the row cap.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 15, 2026

changedInput schema / properties / hours / description

Previous value: -"How far back to look, in hours. Defaults to 48. Capped at 168 keyless and 720 on a paid plan; asking for more returns the cap, and the payload says so in `capped`. The all_time block is unaffected by this window."New value: +"How far back to look, in hours. Defaults to 48. Capped at 168 on the free plans and 720 on a paid plan; asking for more returns the cap, and the payload says so in `capped`. The all_time block is unaffected by this window."

changedInput schema / properties / limit / description

Previous value: -"Max rows returned. Capped at 25 keyless and 500 on a paid plan; asking for more returns the cap, and the payload says so in `capped`."New value: +"Max rows returned. Capped at 25 on the free plans and 500 on a paid plan; asking for more returns the cap, and the payload says so in `capped`."

Changed2 schema fields changedSep 2, 2026

changedInput schema / properties / hours / description

Previous value: -"How far back to look, in hours. Defaults to 48. Capped at 168 keyless and 720 on a developer plan; asking for more returns the cap, and the payload says so in `capped`. The all_time block is unaffected by this window."New value: +"How far back to look, in hours. Defaults to 48. Capped at 168 keyless and 720 on a paid plan; asking for more returns the cap, and the payload says so in `capped`. The all_time block is unaffected by this window."

changedInput schema / properties / limit / description

Previous value: -"Max rows returned. Capped at 25 keyless and 500 on a developer plan; asking for more returns the cap, and the payload says so in `capped`."New value: +"Max rows returned. Capped at 25 keyless and 500 on a paid plan; asking for more returns the cap, and the payload says so in `capped`."

Changed1 schema field changedAug 31, 2026

changedInput schema / properties / limit / description

Previous value: -"Max rows returned. Capped at 50 keyless and 500 on a developer plan; asking for more returns the cap, and the payload says so in `capped`."New value: +"Max rows returned. Capped at 25 keyless and 500 on a developer plan; asking for more returns the cap, and the payload says so in `capped`."

Changed4 schema fields changedAug 13, 2026

addedInput schema / properties / coin / description

Added value: +"Filter to one coin, for example BTC. A pair like ETH/USD works too, the quote leg is dropped. One symbol, not a list. Omit for every coin."

addedInput schema / properties / hours / description

Added value: +"How far back to look, in hours. Defaults to 48. Capped at 168 keyless and 720 on a developer plan; asking for more returns the cap, and the payload says so in `capped`. The all_time block is unaffected by this window."

addedInput schema / properties / type / description

Added value: +"Filter to one signal type. One of: whale-spike, funding-extreme, squeeze-flip, liq-cascade, flow-divergence, major-pctile, major-block, deriv-record. The underscore spellings used by alert rules (for example funding_extreme, or spike for whale-spike) are accepted too. Anything else is refused by name rather than answered as every signal. Omit for all types."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "access_note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "What this connection could not return and what lifts it. Always pass this on to the user: it is the only place that information appears."
+    },
+    "aggregates": {
+      "anyOf": [
+        {
+          "additionalProperties": {},
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "byType: how many fired per signal type inside the window."
+    },
+    "all_time": {
+      "anyOf": [
+        {
+          "additionalProperties": {},
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Permanent counters from the archive, independent of the window asked for: fired, scored_h24, since, through and by_type."
+    },
+    "available": {
+      "anyOf": [
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "False when this lane could not answer: a producer is dark, the pair sits outside this plan, or the argument named something we do not carry. Absent or true means the numbers are a real reading, not a guess."
+    },
+    "capped": {
+      "anyOf": [
+        {
+          "additionalProperties": false,
+          "properties": {
+            "applied": {
+              "description": "The value actually used.",
+              "type": "number"
+            },
+            "argument": {
+              "description": "Which argument was cut down, for example limit or hours.",
+              "type": "string"
+            },
+            "by": {
+              "description": "Why it was cut: keyless for the free ceiling, plan_max for a paid ceiling, tool_max for a ceiling no plan raises.",
+              "type": "string"
+            },
+            "max": {
+              "description": "The ceiling that applied.",
+              "type": "number"
+            },
+            "requested": {
+              "description": "The value the caller asked for.",
+              "type": "number"
+            }
+          },
+          "required": [
+            "argument",
+            "requested",
+            "applied",
+            "max",
+            "by"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Present only when an argument was cut down to a ceiling. Absent means nothing was clamped, so a smaller number than you asked for is the data and not a limit."
+    },
+    "coin": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The coin filter applied, or null for all coins."
+    },
+    "count": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "How many rows this reply carries."
+    },
+    "depth_note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "How far back the data behind this answer reaches."
+    },
+    "hours": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The window actually read, in hours."
+    },
+    "note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "One line saying what the numbers cover, or why there are none. Read it before reporting any zero as a market reading."
+    },
+    "signals": {
+      "anyOf": [
+        {
+          "items": {},
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The signals that fired in the window, each with its type, coin, fire time, price at fire time and later price outcomes where they have been scored."
+    },
+    "total_in_window": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "How many signals fired in the whole window, before the row cap."
+    },
+    "type": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The signal type filter applied, or null for all types."
+    },
+    "unknown_type": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Set when the type asked for is not one this record keeps. Nothing was filtered and nothing was searched."
+    },
+    "valid_types": {
+      "anyOf": [
+        {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The signal types that do exist, returned alongside unknown_type."
+    }
+  },
+  "type": "object"
+}

First observedAug 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description only needs to add non-obvious data behavior. It discloses that records are 'logged live and never backfilled' and that the tool returns 'descriptive market data only', both useful contextual traits. No contradiction with the annotations.

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 short sentences with no filler; the first is front-loaded with the tool's core payload, and the second adds routing and scope. Every clause earns its place despite a minor formatting issue around 'signal_record.Descriptive'.

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 an output schema present and no required parameters, the description does not need to enumerate return fields. It covers freshness, backfill behavior, scope, and the key alternative, leaving only minor domain nuance around 'signal-ledger flags' unexplained.

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 covers all five parameters at 100%, including defaults, caps, and the 'capped' notice in the payload. The description does not add parameter-level detail beyond what the schema already provides, so the baseline score of 3 applies.

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?

The description names the resource ('signal-ledger flags with fire-time price and later price outcomes') and explicitly distinguishes it from signal_record. It lacks a direct retrieval verb like 'list' or 'return', but the title and noun-phrase style still make the operation unambiguous.

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 explicitly routes the single-signal/single-coin case away: 'For one signal type on one coin (how the last N played out) use signal_record.' The first sentence also constrains scope to recently fired, live, non-backfilled data, which tells the agent when this tool is relevant.

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

All whale-data 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.

Resources

Need Help?