Skip to main content
Glama
bykarantelicom

bykaranteli-mcp

by bykarantelicom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Hyperliquid whale tracker: top-300 accounts, long vs short, positions, changes

get_hl_whales
Read-only

Track the 300 largest Hyperliquid accounts, their net long or short positions, liquidation prices, and recent opens, closes, or flips to see what whales are doing.

Instructions

Call this when the user asks what Hyperliquid whales are doing, whether the biggest Hyperliquid accounts are net long or short a coin, for the largest open positions with liquidation prices, or what large accounts just opened, closed or flipped. Returns the live board of the 300 largest accounts by equity (scanned every 5 minutes, addresses only) and with events the last 200 position changes. Without coin, the 30 largest coins and positions; pass coin, or limit (up to 200) for more. Pass detail "compact" for a shorter page or "full" for the whole answer.

Input Schema

NameRequiredDescriptionDefault
coinNoOne coin, e.g. BTC
limitNoOptional. Coins and positions without coin, largest first (default 30).
detailNoOptional. "compact": a shorter page than the default (fewer rows, newest points kept, rounded figures, long text cut, grids left out; every cut named in trimmed). "full" or true: the whole route answer, still under the 100,000 character ceiling (the largest boards answer the ceiling note then: narrow them with symbol, limit or days instead). Omitted or false: the default first page.
eventsNoInclude the last 200 position change events

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / detail
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "enum": [
+        "compact",
+        "full"
+      ],
+      "type": "string"
+    }
+  ],
+  "description": "Optional. \"compact\": a shorter page than the default (fewer rows, newest points kept, rounded figures, long text cut, grids left out; every cut named in trimmed). \"full\" or true: the whole route answer, still under the 100,000 character ceiling (the largest boards answer the ceiling note then: narrow them with symbol, limit or days instead). Omitted or false: the default first page."
+}
  2. Changed1 schema field changedv0.36.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Optional. Coins and positions without coin, largest first (default 30).",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Addedv0.27.2

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds what annotations cannot: the 5-minute refresh cadence, that data is addresses-only, and the 100,000 character ceiling with remediation advice. It does not state degradation behavior when the scan is stale or unavailable, but the substantive behavioral context is present.

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

Conciseness3/5

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

The trigger conditions are correctly front-loaded, but the second sentence is a dense six-clause run-on that merges return contents, defaults and parameter advice into one breath. Every clause carries information, yet the packing forces re-reading and would be clearer split apart.

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?

There is no output schema, so the description must describe returns and does: the live board, positions with liquidation prices, and optional last-200 change events. It stops short of describing the fields per row (entry price, notional, PnL) or the trimmed-metadata behavior, which leaves some ambiguity for an agent reporting results to a user.

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?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the interplay between parameters — without coin the limit applies to the 30 largest coins and positions, and with coin it narrows scope. That cross-parameter relationship is genuinely additive rather than a restatement of the schema.

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?

States a specific verb and resource: a live board of the 300 largest Hyperliquid accounts by equity, with long vs short, positions, liquidation prices and recent changes. An agent can tell this apart from generic positioning tools because the description names the venue, the account population and the ranking metric.

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?

Opens with explicit trigger conditions ("Call this when the user asks what Hyperliquid whales are doing, whether the biggest accounts are net long or short a coin...") covering four distinct question types. It also states default behavior without a coin. It does not name the nearest sibling, get_hl_positions, or say when that is the better choice, so routing against alternatives is left implicit.

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

Deploy Server

Other Tools