Skip to main content
Glama
Sign In
0xarchive-mcp

0xarchive-mcp

by 0xArchiveIO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

get_l2_orderbook

Read-onlyIdempotent

Retrieve Hyperliquid L2 full-depth orderbook with aggregated price levels, total size, and order counts per level. Supports historical snapshots by timestamp and configurable depth.

Instructions

Get Hyperliquid L2 full-depth orderbook (Build+ tier). Returns aggregated price levels with total size and order count per level. Derived from L4 data. Data from March 2026+.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "coin": "<coin>"
    },
    "name": "get_l2_orderbook"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinYesCoin/market symbol, e.g. 'BTC', 'ETH', 'SOL'
timestampNoTimestamp for historical state (Unix ms or ISO). Omit for current.
depthNoOrderbook depth — number of price levels per side

Output Schema

NameRequiredDescriptionDefault
dataYesResult data object

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds behavioral context: returns 'aggregated price levels with total size and order count per level', 'Derived from L4 data', and a temporal limitation. This enriches the agent's understanding of the tool's behavior and data provenance.

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 concise with four sentences, each adding unique value: purpose, output specification, data derivation, and temporal scope. No superfluous information; front-loaded with essential details.

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?

Given the presence of an output schema (context indicates it exists) and well-documented input schema, the description sufficiently covers the tool's functionality. It explains the output format, data source, and tier requirement. Minor improvement could be clarifying the meaning of 'Build+ tier' or the relationship to sibling tools.

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?

The input schema has 100% coverage with clear descriptions for all three parameters (coin, timestamp, depth). The description does not add new meaning beyond the schema, which already adequately documents parameter usage. Baseline of 3 is appropriate.

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 clearly states 'Get Hyperliquid L2 full-depth orderbook' with specific verb and resource. It mentions 'Build+ tier' and 'Derived from L4 data' to contextualize, but does not explicitly differentiate from sibling tools like get_orderbook or get_hip3_l2_orderbook, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching the current L2 orderbook with the 'Build+ tier' requirement and temporal constraint ('Data from March 2026+'), but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_l2_orderbook_history for historical data) or any when-not scenarios.

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