Skip to main content
Glama

What whales are doing with one coin

whale_activity
Read-onlyIdempotent

Everything the recorded whale record can say about ONE coin in one call: net flow over 1h, 4h, 24h and 7d, the CEX / on-chain / Hyperliquid split, which of the 15 streamed CEX venues hold it, and flow measured against price. The plain-English name for whale_profile (identical data and credit cost), and the first tool for a general "what are whales doing with SOL" question. Descriptive market data only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinNoCoin symbol, for example BTC. A pair like ETH/USD works too, the quote leg is dropped. Required: with nothing to look up the call is refused rather than answered about a different coin.
pairNoAlias for coin.
hoursNoHow far back to read the record (min 168, i.e. 7 days). The reported windows are always 1h, 4h, 24h and 7d.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinNoThe coin this profile describes.
noteNoOne line saying what the numbers cover, or why there are none. Read it before reporting any zero as a market reading.
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.
caveatNoA real limit on this answer, in one clause. Present only when something genuinely narrows what can be said.
venuesNoWhich of the streamed exchanges the flow actually sits on and how concentrated it is. split marks two exchanges on opposite sides; partial marks a window whose exchange dollars are unknown rather than zero.
sourcesNoThe CEX, on-chain and Hyperliquid split, including sourceSplit when those markets sit on opposite sides.
summaryNoThe answer in one plain sentence, computed from the fields below. Open the reply with this, then let the numbers back it up. Null only when there was nothing to summarise.
windowsNoNet flow per window, keyed 1h, 4h, 24h and 7d. A window states hoursCovered only when it holds fewer hours than it spans.
coverageNoHow much of the window carries a recorded reading.
pressureNoFlow measured against price. state is absorption, distribution or confirming. When there is no state, reason names why (price-coverage, flow-too-small, price-flat), which means not enough to say, never no activity.
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.
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.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds value by emphasizing 'Descriptive market data only' and clarifying that this is identical in behavior and cost to whale_profile. It does not contradict any annotation and gives extra semantic context about the nature of the data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but not bloated, front-loading the main purpose and then enumerating specific outputs. The phrase 'recorded whale record' is slightly awkward, but the structure is efficient and informative without unnecessary filler.

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?

Given the rich output schema, annotations, and the tool's complexity, the description covers the core selection-relevant context: what data is returned, that it is descriptive, and how it relates to whale_profile. It could add an example or clarify input constraints beyond the schema, but it is sufficiently complete for an agent to call it 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 parameters are already documented at the schema level. The tool description does not add much parameter-level detail, but it reinforces the 'one coin' focal point. This meets the baseline for a fully schema-documented tool.

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 ('ONE coin'), a clear scope ('net flow over 1h, 4h, 24h and 7d...'), and the exact output categories. It also differentiates itself from whale_profile by explicitly stating it is the 'plain-English name' with identical data and credit cost. This gives an agent a precise understanding of what the tool does.

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 provides actionable usage context: it is 'the first tool for a general "what are whales doing with SOL" question' and positions itself as the human-friendly alias for whale_profile. It does not explicitly spell out when not to use it, but the use-case framing is clear enough for tool selection among many siblings.

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