Skip to main content
Glama

whale-data

by com.coinlobster
OverviewDiscussionsAdmin

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.
coinsNoPortfolio read: a list of coin symbols (or a comma-separated string) answered side by side in one call, up to 10. Omit for one 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / coins
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "string"
+    }
+  ],
+  "description": "Portfolio read: a list of coin symbols (or a comma-separated string) answered side by side in one call, up to 10. Omit for one coin."
+}
  2. Added

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds 'Descriptive market data only' and notes identical data and credit cost relative to whale_profile, which is useful context but not a deep behavioral disclosure. No contradiction exists.

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 efficient, front-loading the key purpose and data contents before the alias and usage note. It earns its length by covering scope, sibling relationship, and data characteristics without repeating the schema.

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?

For a tool with four fully documented parameters, rich annotations, and an output schema, the description covers what an agent needs to select the tool and understand its output. It clearly explains the data scope, the use case, and the relationship to whale_profile. A slightly more explicit note about the portfolio-read behavior would round it out, but the schema already covers that.

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 documents all four parameters thoroughly. The description adds general meaning around the single-coin focus and the reported time windows, but it does not need to restate parameter details because the schema carries them.

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 action and resource: it returns everything the recorded whale record can say about ONE coin, and enumerates the exact data included (net flows, CEX/on-chain/Hyperliquid split, venues, flow vs. price). It also explicitly distinguishes itself from whale_profile by calling itself the plain-English name for the identical data and credit cost, so an agent can differentiate it from siblings.

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 clearly positions the tool as the first stop for a general 'what are whales doing with SOL' question and states that it is the plain-English alias for whale_profile with identical data and credit cost. It does not enumerate when to prefer other whale-related siblings like whale_flow or whale_context, but the usage context is clear enough for selection.

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