An agent in 2026 doesn't need more data. It needs better data access. That's the entire reason we built EVIDIQ Atlas as an AI dataset analysis MCP: a tool surface that lets an autonomous agent ask precise questions about a dataset, get structured answers back, and pay only for what it actually used. No more cramming a 2GB CSV into a context window. No more hallucinating column statistics. No more opaque "trust me, bro" summaries.
What Is a Dataset-Analysis MCP?
EVIDIQ Atlas is the AI dataset analysis MCP we built for agents that need to reason over data they don't want to ingest wholesale. It's a remote MCP server exposing five paid tools — profile, query, visualize, compare, and research — plus free helpers, with all paid tools metered per call through x402 on X Layer in USDT0.
Here's the thing: most agents treat every dataset like a black box. They see a URL, a filename, a vague summary, and then they guess. We wanted a primitive where the agent calls the data — profile a sample, run a query, get a chart spec, compare two cohorts, or commission deeper research — and pays proportionally to the depth of the answer it needs. Cheap calls for cheap answers. Expensive calls for richer outputs.
That's also why we ship it through the same install path our other products use. An agent loads the open Agent Skill at evidiq.dev/skill.md, registers the Atlas MCP server, and immediately has a contract for "what to do with a dataset I just found." No bespoke glue code per integration. The full surface is documented in the EVIDIQ docs, and the trust-scoring sister product lives one tab over.
Five Tools, Priced by Depth
Atlas exposes the work through five paid tools and a few free companions. The pricing tracks how much compute each call costs us to serve — a fast summary is cheap, a multi-pass research job is not. Agents pick the tier that matches the question.
The paid surface:
- profile_dataset — cheap tier. Returns schema, column types, row count, missingness, basic stats. The "what is this file" call.
- query_dataset — mid tier. Runs a bounded SQL-style query against a sandboxed view and returns rows plus a summary.
- visualize_dataset — mid tier. Returns a chart spec (axes, encoding, dtype) the agent can render or hand to a human.
- compare_datasets — higher tier. Diff two datasets on schema, distribution, or a user-supplied metric; returns a comparison report.
- research_dataset — top tier. Multi-step research mode: cross-references related datasets, runs sub-queries, returns a written narrative plus artifacts.
The free helpers matter too, and an agent should call them before spending money:
- atlas_capabilities — returns the current tool catalog and prices. Free, idempotent.
- validate_dataset_source — checks whether a URL or storage handle is reachable and parseable, without running analysis. Free.
- estimate_cost — given a tool plus its inputs, returns the USDT0 price the agent is about to pay. Free, no surprise bills.
- verify_atlas_report — given a report hash, returns the on-chain anchoring tx and signed verdict for independent verification. Free.
- get_artifact — fetches a previously returned artifact by id. Free.
The depth-to-cost relationship is intentional. A profile call is a few-second scan. A research call might spawn sub-queries, run comparisons across related files, and produce a multi-page write-up. Charging the same flat fee would either ruin us on the heavy calls or overcharge for the light ones. Pay-per-depth is the honest model.
Worth noting: every paid call follows the x402 flow. Your agent sends a request, receives a 402 Payment Required with accepts[].amount in USDT0, signs an EIP-3009 transferWithAuthorization, and retries. Once settled on X Layer, the response comes back. No accounts, no API keys, no rate-limit emails — just a signed receipt per call. Atlas fits cleanly into the same payment model verify_agent already uses for trust scoring.
Why an Agent Should Not Swallow a 2GB CSV
Picture this: a research agent has been handed a 2GB CSV of supplier shipment records. It tries to "read" the file. The tokenizer chokes. The context window fills with the first 80,000 rows and truncates the rest. By the time the agent reasons, it has statistically meaningful answers only for whatever happened to land in the head of the file, plus a confident hallucination about the tail.
That's the failure mode Atlas was designed to kill.
The smarter move is what we'd call out-of-context analysis — keep the bytes outside the model's context, and pull only the answers in. Concretely, an agent that wants to understand that shipment file calls profile_dataset first. It gets back something like:
{
"rows": 4_812_004,
"columns": 17,
"schema": [{"name": "ship_date", "dtype": "datetime"}, ...],
"missing_pct": {"supplier_id": 0.4, "weight_kg": 12.1},
"stats": {"weight_kg": {"mean": 18.4, "p95": 47.0, "max": 412.0}},
"sample": [...10 rows...]
}
That's a structured artifact the agent can reason about without ever seeing the file. If it now needs to know how many shipments exceeded 50kg in Q2 2026, it calls query_dataset with a bounded filter and gets back a one-line answer plus the evidence. The 2GB CSV stays in storage; the agent's context stays small; the answer is grounded in actual data, not vibes.
Honestly? The same logic applies to almost any large file. A 600-page PDF that an agent "summarizes" by squishing into context loses structure, loses citations, and loses reliability. Tools are better than context when the data is big.
This is the same philosophy behind how we treat every other interaction in our stack — verify capabilities with a live probe instead of trusting a description, score an agent's identity before delegating, anchor evidence on-chain instead of in memory. The EVIDIQ docs capture the broader pattern; Atlas is just the dataset-shaped instance of it.
Verifiable Analysis, Not a Black Box
A common pushback we hear: "How do I know the chart Atlas returned actually came from the data you had?" Fair. We treat every paid output as a piece of evidence, the same way our trust verification tooling does.
Every Atlas report goes through this pipeline:
- The analysis runs deterministically where it can (profile stats, SQL filters, distribution diffs).
- The final report JSON is canonicalized and hashed (keccak256).
- The hash is anchored on 0G Storage mainnet, which returns an on-chain transaction id.
- For deeper calls, we can optionally run an AI risk analysis on 0G Compute with GLM-5.2 inside a TEE, recording the provider address and request id alongside the report.
- The verifier signs the canonicalized hash with the EVIDIQ key using EIP-191.
The signed report is what your agent receives. Anyone — including the agent's owner, a downstream counterparty, or our own tooling — can re-fetch the evidence, re-hash it, and recover the signer from the signature. This is the same evidence model you'll find in the EVIDIQ Sentinel docs for trust scoring and the EVIDIQ Notary docs for tamper-evident certificates. One shared root, multiple products.
The math is simple: a black box is fine when the consequence of being wrong is a bad summary. A black box is unacceptable when the consequence is a procurement decision, a credit call, or a regulator-facing report. We built Atlas so the analysis itself is auditable, not just the agent that asked for it.
For agents running Atlas inside a multi-step pipeline (Operator-style workflows), the verify_atlas_report helper makes re-verification cheap, so any downstream node in the graph can confirm what its predecessor actually saw. You can read more about how this slots into end-to-end agent orchestration in the EVIDIQ Operator docs. The same hash-and-sign discipline applies whether the artifact came from Atlas, a trust score, or a notarized certificate.