Querying Datasets From an AI Agent, Defined
To query datasets from AI agents means calling an MCP tool with a structured request and getting structured findings plus artifacts back, instead of ingesting raw rows. EVIDIQ Atlas is a pay-per-call implementation: every query_dataset or compare_datasets call is metered over x402 and returns JSON plus a receipt.
Most "AI + data" stacks still look like this: dump the CSV into the prompt, hope the model can find the answer, accept whatever hallucinations the context window didn't suppress. That's not how an engineer would do it. We built Atlas around the opposite assumption — data stays at the source, the agent asks a precise question, and only the answer crosses the wire. The agent never holds the table.
Practically, Atlas is a remote MCP server (see the EVIDIQ docs) that exposes a small, opinionated tool surface. The agent speaks JSON-RPC over HTTP, gets a 402 Payment Required challenge on first use, signs an EIP-3009 transferWithAuthorization for USDT0 on X Layer, and then receives a structured result with the dataset digest, the matched rows, and a signed receipt. Same shape, every run. No hidden rate limits behind a sales call.
The Context-Window Tax Nobody Budgets For
Here's the math nobody runs. A 200k-row CSV with five columns is roughly 8–14 MB of text. Tokenized, that's 2–4 million tokens — already over the context ceiling of most production models. Compress it down to "just the relevant columns" and you've still moved 300–600k tokens through inference, paying for every one.
The bill has three parts, and they compound:
- Token cost. $3–$15 per million tokens on the cheap end. A single full-table pass can cost more than the agent's entire prompt history for the day.
- Latency. TTFT climbs nonlinearly once you cross ~100k tokens in the prompt. A 500k-token context often adds 6–14 seconds before the model produces a single character.
- Accuracy loss. Models get sloppy in long contexts. The "lost in the middle" effect is real and reproducible: needle-in-haystack recall drops 15–40% as the needle drifts away from the start and end of the prompt.
So the same query, executed two different ways, can produce wildly different bills and wildly different answers — and almost nobody measures both. Builders who query datasets from AI agents through Atlas see this directly, because every call has a price tag and a response time you can actually chart.
An Atlas call flips this. Instead of shipping the table, the agent ships a request through a bounded MCP tool call: "rows where region = 'EU' AND cohort = '2026-Q1', grouped by plan_tier, return count and median LTV." Atlas returns the answer — typically a few hundred bytes — and the agent reasons over the result. The raw rows never leave the dataset source. The signature on the response is what proves the answer came from that source and not from a hallucinated mid-prompt interpolation.
A wallet balance alone tells you nothing about intent; the same is true for a CSV dump — neither proves what the agent actually needed.
Honestly? Context-dumping is the wrong default. It's the 2026 equivalent of pasting your database into a Slack thread. Atlas is what you'd build instead — bounded payload in, bounded payload out, priced per query.
One Question, One Priced Call
Let's walk one real flow. A builder's agent needs to query datasets from AI agents to know whether two product cohorts behaved differently after a pricing change in February 2026.
The sequence:
- The agent calls
estimate_cost(query_dataset, params)first — free, signed with the agent's EVIDIQ key — and gets back an x402 quote plus an estimated runtime in milliseconds. The agent can show the user the cost before spending anything. - On approval, the agent sends
query_dataset({dataset: "cohorts_2026", filter: {after: "2026-02-15"}, group_by: "cohort"}). - Atlas responds with a
402 Payment Requiredcarrying theaccepts[]payload — schemeexact, networkxlayer, assetUSDT0, amount in atomic units. - The agent signs an EIP-3009
transferWithAuthorization, replays the request, and Atlas settles on X Layer, executes the query against the source, hashes the result, and returns a structured envelope. - For the second cohort, the agent calls
compare_datasets({left: ..., right: ..., metric: "retention_30d"})and receives a delta plus the same artifact shape.
Every response carries three things the agent can act on:
- result — the actual answer, never the raw rows.
- artifact — a canonical JSON of the query, the source URI, the timestamp, and the result hash.
- receipt — the on-chain settlement tx hash, the Atlas operator's EIP-191 signature over the artifact, and the keccak256 of the canonical payload.
That receipt is what makes the answer auditable downstream. The agent can drop it into a Notary call later and prove, after the fact, exactly which dataset was queried, when, and what came back. If you're already running EVIDIQ Sentinel docs to gate which datasets an agent is allowed to touch, Atlas is the natural next call in the same flow.
Where Atlas Fits Next to Sentinel and Notary
Three tools, one x402 surface. Here's the mental model:
- Sentinel answers: can this agent touch this endpoint, and what's its trust score? A bounded ~6s probe, a deterministic 0–100 score, and a recommendation (
proceed,proceed_with_escrow,caution,do_not_proceed). - Atlas answers: what does the data actually say? A priced query against a specific dataset, returning structured findings the agent reasons over.
- Notary answers: can I prove what the model produced? A tamper-evident receipt anchored on 0G Storage mainnet, optionally with an AI risk analysis run on 0G Compute inside a TEE.
We didn't design them as three separate products — they sit on the same MCP server, paid for with the same USDT0-on-X-Layer rail. An agent's "investigate this dataset before I act on it" loop becomes: Sentinel the source, Atlas the data, Notary the decision. Each step is one priced call, signed, settled, and receipted on chain.
Operators who run their own MCP endpoints can plug Atlas into a EVIDIQ Operator docs deployment and expose it under their own namespace — the EVIDIQ Notary docs cover the receipt-anchoring side, and the EVIDIQ main page has the installable Skill that wires all three into Claude, Cursor, or any MCP-aware client. The combined surface lets a single agent query datasets from AI agents with a payment rail you can audit on a block explorer.