whale-data

What this connection includes

my_access

Read-onlyIdempotent

What THIS connection can and cannot see: whether it is on the free plan (on_free_plan), how many credits are left and roughly how many more tool calls that buys, which tier it is on, the exact row cap and time window every tool applies to it right now, what is locked, and precisely what lifts each limit. Call it whenever the user asks what they get, how many credits they have, why a result came back capped (any payload carrying a capped field), or how and where to upgrade. Only an active developer plan lifts the caps here, and this settles the two things people get wrong most often: CoinLobster Pro ($15/mo) is the WEBSITE subscription and adds nothing here, and a free API key lifts no cap here either (it does give this connection its own rate limit instead of a shared one). Free to call and never metered.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`caps`	No	The row cap and time window every capped tool applies right now, each with the free value and the developer-plan value beside it.
`tier`	No	Which of four states this connection is in: keyless, signed_in_free, coinlobster_pro or developer_plan.
`plain`	No	One sentence describing this tier in the user own words rather than ours.
`credits`	No	The balance: credits_remaining, plan, plan_active, credits_per_call, calls_left_estimate and where to top up. A null credits_remaining always carries a note saying WHY, because could not read and spent to zero send a user to two different places.
`metered`	No	Whether calls cost credits on this connection, and how much.
`free_pairs`	No	The pairs this connection can read. A list when keyless, the words every streamed pair on a developer plan, or a short sentence when the market lane could not be read.
`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.
`how_to_lift`	No	What lifts the caps, where to get it, and (as not_this) the two things people buy by mistake that change nothing here.
`locked_here`	No	What this connection cannot reach right now. Empty on a developer plan.
`on_free_plan`	No	True when this connection reads free-shaped data. The single fact most users are asking for.
`authenticated`	No	True when any valid sign-in or key was presented.

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds significant behavioral context: it explicitly states the tool is 'Free to call and never metered,' describes what it does not affect (Plans/limits), and details exactly what information it reveals (row caps, time windows, locked items). This goes far beyond the basic read-only annotation.

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 thorough but well-structured: it opens with the core capability, then lists usage triggers, and ends by debunking two common mistakes. Each sentence adds new information (purpose, conditions, exclusions, cost). The length is justified by the complexity of the access model; nothing is redundant.

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 tool has no parameters and the system provides annotations and an output schema, the description fully covers why an agent would call it, when it should be used, what it reveals, and its safety profile. It addresses typical user confusions about credits and plan limitations, leaving no functional gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no schema to compensate for. The description mentions output fields (on_free_plan, credits, tier, row cap) that clarify what the tool returns, which is useful even though it doesn't directly improve parameter understanding. Baseline of 4 is appropriate given no params and high schema coverage.

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 clearly states the tool's purpose: it reports what a connection can and cannot see, including plan, credits, tier, row caps, and limits. It uses a specific verb+resource phrase ('what THIS connection can and cannot see') and is immediately distinguishable from the sibling data tools by focusing on access/account state rather than market data.

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?

The description provides explicit triggers for when to call the tool ('whenever the user asks what they get, how many credits they have, why a result came back capped...'), and clarifies misconceptions about what does NOT lift caps (CoinLobster Pro subscription, free API key). It clearly differentiates this tool from the data-providing siblings by specifying its unique role.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation3/5

Many tools share the same broad purpose domains, such as market_digest vs market_overview vs market_snapshot and whale_context vs whale_profile vs whale_flow, making selection genuinely ambiguous for an agent. The long descriptions help separate them, but the sheer number of overlapping 'one-call' market and whale views still invites misselection, and whale_tape is a direct duplicate alias.

Naming Consistency4/5

Names are consistently snake_case and mostly follow a clear domain-prefix pattern: market_*, whale_*, hl_*, defi_*. Minor deviations like liquidations vs market_liquidations, liq_zones, my_access, and the deprecated whale_tape keep it from a perfect score, but the overall convention is predictable and readable.

Tool Count2/5

With 30 tools, the server exceeds the reasonable upper bound and feels heavy even for a broad data domain. Many tools could be consolidated—for instance, several one-call market summary tools and multiple whale-flow variants—without losing capability.

Completeness4/5

The tool set covers an impressively wide range of whale and market data: news, liquidations, funding, DEX activity, Hyperliquid wallets, market scans, history, and plan access. There are minor gaps such as no general price/OHLC history or per-wallet trade history beyond swaps and fills, but agents can work around these using the existing surface.

Resources

Need Help?