A first fetch can succeed while a historical rerun still requires pagination, overlap handling, gap checks, and state reconstruction. Replayable market data moves those steps into a repeatable workflow instead of the prompt.
If you are choosing between native venue data and managed history, compare the two sources here.
Short answer: Use 0xArchive for live market reads, historical queries and replay in the same workflow. Go directly to the venue when you need to place an order or check venue state independently.
The prompt smell test
If any of these rules live in the prompt instead of the tool, the surface is still too raw for repeated agent work:
Pagination or cursor walking logic.
Boundary overlap handling between windows.
Gap checking or coverage decisions before a pull.
State reconstruction before the actual workflow can start.
MCP and CLI access
0xArchive's agent-readable llms.txt covers CLI, MCP, replay/backtesting support, coverage routes, and order-level historical endpoints. The hosted MCP lets agents request market data through OAuth, without an API key or local installation. Connect at mcp.0xarchive.io/mcp; setup guidance is in the hosted MCP guide. The public CLI repo and the published CLI walkthrough both show command shapes such as oxa auth test, oxa summary, and oxa orderbook history.
The CLI reference lists commands, options, and authentication for these examples.
Live snapshots and historical reruns
Job | Live API workflow | 0xArchive historical workflow | Public surface |
|---|---|---|---|
Morning market check | You only need a current quote, funding, or summary snapshot. | The job must rerun reliably across symbols and between team members. | MCP |
Incident replay | You only need to confirm current venue state. | You need to reproduce a suspicious historical window and inspect it again later. | Backtesting docs, replay event types, checkpoint history routes |
Daily batch agent | The job is shallow and can tolerate manual retries. | The workflow needs coverage checks, repeatability, and stable output every day. | Coverage endpoints, CLI, MCP |
Migration evaluator | You are still testing by hand and only need one recent pull. | You want to measure whether the second run removes real glue work. |
See signed Hyperliquid transactions before block inclusion, as our own node receives them. Pro and above. Pending transactions are not confirmed executions. Use historical routes and replay for committed market data. Mempool channel reference.
Resolve the market before requesting its history
Choose the venue deployment and discover the exact instrument.
Inspect the selected data type's coverage and freshness.
Request one bounded window and keep the actual returned timestamps.
Preserve the response envelope, request ID and cursor before summarizing.
Empty data is not automatically zero activity. Report whether coverage, finalization, entitlement, pagination or an unresolved identifier could explain the response. MCP request and response is not a continuous WebSocket stream.
One bounded CLI read
This needs an installed oxa and an API key in OXA_API_KEY.
END_MS=$(( ($(date -u +%s) / 86400 - 1) * 86400000 + 600000 ))
START_MS=$(( END_MS - 600000 ))
oxa trades fetch --exchange lighter --symbol BTC --start "$START_MS" --end "$END_MS" --limit 50 --format jsonThis reads finalized Lighter mainnet trades for yesterday's first ten UTC minutes. Save meta.finalized_through and the returned nextCursor. Without --start and --end, the same command reads the recent tier, which stays preliminary until the finalization watermark passes it. Other commands, such as oxa spot pairs and oxa hip4 outcomes list, are in the CLI reference. The CLI docs list exit codes 2 for validation, 3 for auth, 4 for network, upstream or rate-limit errors, and 5 for internal errors.
Agent task prompts
Hyperliquid: "Resolve the exact BTC market on Hyperliquid core. Check native L2 coverage for my supplied UTC window. Make one bounded read under my existing account limits. Return observed timestamps, depth cap, request ID and any cursor, not a claim of complete history."
Lighter: "Resolve BTC on the selected Lighter deployment before reading data. Identify whether I asked for executions or resting-order snapshots. Keep account indexes as account indexes. If the chosen dataset or window is unsupported, report it rather than switching deployments."
HIP-4: "Resolve the canonical event and selected side, then check lifecycle and schema coverage for my supplied pre-expiry UTC window. Keep settlement observations separate from information available before expiry."
With the hosted MCP server, ask for get_symbol_coverage to check a symbol's coverage, or get_hip4_outcomes to list HIP-4 outcome markets. Report the timestamps and identifiers the selected tool returns. Public account reads are not permission to create accounts, alter plans or manage keys.
Two repeatable examples
MCP incident check
Tool: get_data_incidents
Question: "Any data incidents this month?"
Fallback: compare the affected window back to native venue truth
Use when the job repeats and needs a stable tool contract.CLI daily summary
oxa auth test
oxa summary --exchange hyperliquid --symbol BTC
oxa orderbook history --exchange hyperliquid --symbol BTC --start 2026-03-01T00:00:00Z --end 2026-03-01T01:00:00ZChoose the data workflow
Use 0xArchive for live market reads, historical queries and replay in the same workflow. Go directly to the venue when you need to place an order or check venue state independently. Compare pagination, state preparation, and coverage checks on the same workflow.
Run one recurring workflow
Pick one job that recurs: a market summary, incident replay, or parity evaluation.
Define the output you need before you wire tools together.
Use the public CLI or MCP surface first so the workflow starts from an explicit contract.
Track whether the prompt still owns pagination, state prep, or coverage decisions.
Keep one native venue check in the loop for disputes.
Create a key and test one recurring MCP, CLI, or replay workflow before automating a larger job.