Skip to main content
Glama

whale-data

by com.coinlobster
OverviewDiscussionsAdmin

Signal outcomes (what happened after)

signal_outcomes
Read-onlyIdempotent

Recorded signals with the price when each fired and the price afterwards, logged live and never backfilled: whether a whale, funding or other signal has historically led anywhere. The plain-English name for flag_outcomes (identical data and credit cost). Descriptive market data only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinNoFilter 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.
pairNoAlias for coin.
typeNoFilter 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.
hoursNoHow 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.
limitNoMax 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
NameRequiredDescriptionDefault
coinNoThe coin filter applied, or null for all coins.
noteNoOne line saying what the numbers cover, or why there are none. Read it before reporting any zero as a market reading.
typeNoThe signal type filter applied, or null for all types.
countNoHow many rows this reply carries.
hoursNoThe window actually read, in hours.
cappedNoPresent 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.
signalsNoThe 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_timeNoPermanent counters from the archive, independent of the window asked for: fired, scored_h24, since, through and by_type.
availableNoFalse 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.
aggregatesNobyType: how many fired per signal type inside the window.
depth_noteNoHow far back the data behind this answer reaches.
access_noteNoWhat 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_typesNoThe signal types that do exist, returned alongside unknown_type.
unknown_typeNoSet when the type asked for is not one this record keeps. Nothing was filtered and nothing was searched.
total_in_windowNoHow many signals fired in the whole window, before the row cap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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`."
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: signals are logged live and never backfilled, the data is identical to flag_outcomes, and it is descriptive only. This is more than the annotation baseline, though it does not detail response behavior, which the output schema covers.

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 description is two sentences with no filler. It front-loads the core concept, then adds the alias and safety framing efficiently.

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 the rich parameter schemas, output schema, and safety annotations, the description is complete for invocation. It covers what the tool returns conceptually, the key data limitation (never backfilled), and the relationship to flag_outcomes.

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 the schema already fully documents all five parameters. The description does not need to add parameter-level guidance, and it does not meaningfully do so; the baseline score of 3 is appropriate.

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 states a specific resource: recorded signals with the price at trigger and afterward, which is clearly a historical outcome analysis tool. It also names flag_outcomes as the identical sibling, so an agent can distinguish signal_outcomes from related tools without inspecting schemas.

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 explicitly points to flag_outcomes as the identical alternative and frames the tool as 'descriptive market data only,' which gives clear selection context. It does not spell out when to prefer this over other signal-related siblings, but the alias relationship largely covers the main ambiguity.

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

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