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: if the job is a one-off quote or a recent snapshot, raw API access is often enough. If the workflow has to rerun cleanly, reproduce an incident window, or stay deterministic across repeated jobs, the historical layer starts to matter much more than the first fetch.
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.
What you can check today
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.
Where raw API access is enough and where replayable history helps
Job | Raw API is enough when... | Replayable history is worth testing when... | 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. |
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:00ZWhen this framing is overkill
If you are exploring ideas by hand or only need recent-window pulls, raw API access is usually enough. Teams with mature collectors and replay loaders may not need another layer. For recurring work, compare how much pagination, state preparation, and coverage checking remain in the workflow.
How to test one workflow without overcommitting
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.