Vike Data API

Hyperliquid Leverage Changes

hl_leverage_changes

Read-onlyIdempotent

Hyperliquid positions whose leverage or margin mode differs between two consecutive complete position snapshots, newest first: one row per wallet and symbol with the previous and the new leverage, margin mode, side, size and entry price. ts is when the later snapshot was written, not when the venue changed the setting; positions are captured about every 12 minutes, so changes arrive in batches. Without wallet the window defaults to the last 24 hours and is at most 31 days. order=asc follows the feed (stop on an empty page). Same data as GET /v1/hyperliquid/leverage-changes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "hl_leverage_changes"
  }
}

Input Schema

Name	Required	Description	Default
`end`	No	ISO-8601 UTC upper bound. Default: now. A window wider than 31 days is refused unless `wallet` is given.
`limit`	No	Rows per page. Max 5000.
`order`	No	`desc` (default, newest first) or `asc`, oldest first: the mode for FOLLOWING the feed. Pass each `nextCursor` back verbatim and stop on an EMPTY page, not on a null cursor (an `asc` page with rows always carries one). A row written late with an older key is not seen by a poller already past it: re-read a small overlap with `start`.	desc
`start`	No	ISO-8601 UTC lower bound. Default: the 24 hours before `end`, unless `wallet` is given.
`change`	No	`up` (leverage rose), `down` (leverage fell) or `mode` (only the margin mode, `cross` or `isolated`, changed). Omit for every change.
`cursor`	No	`nextCursor` from the previous page, verbatim. It pins the call that returned it: send the same `order`, filters, `start` and `end` again, or the call is refused.
`symbol`	No	Hyperliquid instrument ticker, e.g. BTC, ETH, HYPE; a HIP-3 market is `dex:TICKER`, e.g. xyz:TSLA. Omit for all symbols.
`wallet`	No	One wallet, 0x followed by 40 hex characters, any case. With it there is no default window and no 31-day cap.
`min_leverage`	No	Smallest NEW `leverage`, 0 or more. Default 0: no floor.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, but the description adds genuinely non-obvious behavior: snapshots are written roughly every 12 minutes so changes arrive in batches, `ts` is the snapshot write time rather than the venue change time, and late-written rows can be missed by an advancing poller unless a small overlap is re-read. That is exactly the kind of caveat an agent cannot get from structured fields.

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?

Four sentences, front-loaded with the row semantics before pagination and window rules; every sentence carries information. There is mild duplication of the cursor/order guidance that the schema already states verbatim.

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 no output schema and nine parameters, the description discharges the burden by describing the returned row, the sort order, the time-window defaults and caps, and the feed-following protocol. An agent can call this correctly and interpret the result without further context.

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 coverage is 100% and the schema descriptions are themselves detailed (including cursor pinning and the empty-page stop rule), so the description's parameter-level statements largely restate them. It adds a modest amount — the wallet-dependent window override and the batching implication for `start`/`end` — but nothing beyond baseline against a schema this rich.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a precise verb-and-resource definition: positions whose leverage or margin mode differs between two consecutive complete snapshots, with the row shape (wallet, symbol, previous/new leverage, margin mode, side, size, entry price) spelled out. It is unmistakably distinct from generic feed siblings like hl_wallet_activity, but no sibling is named explicitly, so an agent must infer the routing rather than being told it.

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?

It states concrete operating conditions: default 24-hour window without `wallet`, a 31-day cap, and that `order=asc` is the mode for following the feed and stops on an empty page. What it lacks is an explicit 'use X instead when…' comparison against neighbouring position/wallet tools.

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

All Vike Data API tools Inspect

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.