Skip to main content
Glama

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 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.
limitNoMax 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`.

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.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description adds meaningful behavioral context: data is 'logged live and never backfilled', it has identical credit cost to flag_outcomes, and it is 'descriptive market data only'. This gives an agent operational expectations that annotations alone do not convey.

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 three dense, purposeful sentences: what the tool does, the live/backfill behavior, and the sibling alias. There is no filler, and the most important semantic is front-loaded.

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?

With full parameter schema coverage, an output schema present, and annotations covering safety and idempotence, the description adds the remaining needed context: data provenance, alias relationship, cost, and descriptive nature. Nothing material is missing for an agent to select and invoke this 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?

Schema description coverage is 100%, so the parameter schema already documents coin, pair, type, hours, and limit thoroughly. The description adds no per-parameter meaning beyond what the schema provides, which puts it at the baseline of 3.

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 exactly what the tool returns: recorded signals with the price at fire time and afterwards, showing whether signals historically led anywhere. It also explicitly identifies itself as the plain-English alias for flag_outcomes, which distinguishes it from a key sibling without needing to inspect 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 names flag_outcomes as the identical counterpart and notes the same data and credit cost, which effectively tells an agent this tool is interchangeable with that sibling. It does not provide broader when-to-use versus other sibling tools, but for a tool that is an alias this is adequate context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation2/5

The set contains at least five exact alias pairs (coin_liquidations/liquidations, market_brief/trade_context, flag_outcomes/signal_outcomes, whal_activity/whale_profile, whal_tape/whale_trades) plus many near-synonymous market_, whal_, hl_, and liquidation tools. The descriptions are excellent and cross-reference each other, but the sheer density of overlapping names makes tool selection genuinely difficult for an agent.

Naming Consistency4/5

Names are uniformly snake_case and largely follow a domain-prefix + noun convention (market_*, whale_*, hl_*, defi_*). Minor deviations exist: standalone liquidations, my_access, and duplicate aliases with different names, but the overall style is predictable and not mixed.

Tool Count2/5

38 tools is well past the 25+ threshold for a heavy toolset, and roughly ten of them are redundant alias pairs that could be collapsed into five. While the domain is broad, many one-call briefs and whale-flow variants overlap enough that the count feels inflated rather than justified.

Completeness4/5

The surface is remarkably broad for a read-only data server: price, funding, open interest, liquidations, whale flows, DeFi, options, news, signals, and access controls are all covered. Minor gaps remain, such as no explicit supported-pairs listing and some paid-tier caps that can surprise agents, but these are workaroundable.

Resources