Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Hyperliquid Archive

hl_archive
Read-onlyIdempotent

Index of the Hyperliquid Parquet archive and download links to its files. One file per UTC day for fills (every fill) and positions (every 5-minute snapshot of every open position), from 2026-05-01, plus latest, one positions file of the current open positions replaced every 5 minutes. view='datasets' (default) lists the published days with each file's rows and bytes, the column schema of both datasets and the free samples' folder. view='url' resolves exactly ONE file (dataset and date) to a link valid for 7 days (expires_at) that needs no API key: this tool never downloads anything, so fetch it yourself and do not share it. A day appears once it is complete (the early UTC morning after). Same data as GET /v1/hyperliquid/archive/datasets and /archive/url.

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_archive"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoview=url only, required there: a published UTC day, YYYY-MM-DD, or `latest` (`positions` only: the current open positions).
viewNodatasets = the index (default); url = a link to one file.datasets
datasetNoview=url only, required there: `fills` or `positions`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses that URLs expire in 7 days (`expires_at`), need no API key, must not be shared, that the tool itself never downloads, that a day only appears after it completes (early UTC morning after), and that `latest` rotates every 5 minutes. These are exactly the behavioral facts an agent cannot infer from schema or annotations.

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?

Front-loaded with the resource identity, then the view semantics, then the caveats; no filler sentences. The single dense paragraph packs a lot in, but some clauses (the HTTP endpoint equivalence) are secondary and could be trimmed.

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, the description carries the burden and does: it enumerates what the datasets view returns (`rows`, `bytes`, `schema` for both datasets, samples folder) and what the url view returns (link plus `expires_at`). An agent has everything needed to choose a view and act on the result.

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 already documents the view=url-only requirement for `date` and `dataset`, including `latest` being positions-only. The description restates those relationships rather than adding new syntax or format detail, so the baseline 3 applies.

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 resource ('Index of the Hyperliquid Parquet archive and download links to its files') and immediately splits it into the two distinct operations the tool performs: the day index and the single-file URL resolution. The distinction from adjacent tools like polymarket_archive is implicit in the 'Hyperliquid' scoping and the concrete dataset names (`fills`, `positions`).

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?

Explicitly says which view to pick: 'view=datasets' (default) lists published days, 'view=url' resolves exactly ONE file and requires `dataset` and `date`. It also gives the operational follow-up ('this tool never downloads anything, so fetch it yourself') and notes the equivalent HTTP endpoints. It doesn't contrast against sibling tools, which is the only gap.

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 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