EVIDIQ Atlas: The AI Dataset Analysis MCP Agents Actually Pay For

What Is a Dataset-Analysis MCP?

EVIDIQ Atlas is an AI dataset analysis MCP that exposes five x402-paid tools for profiling, querying, visualizing, comparing, and researching datasets on demand. Instead of forcing an agent to ingest an entire file, Atlas returns structured findings, visualizations, and signed artifacts — paying only for the depth of analysis each call requires.

Strip the marketing away and an MCP is just a contract: a JSON-RPC surface a model can call, the way it would call any tool. A dataset-analysis MCP is one built specifically to answer questions about data — its shape, its contents, its quirks, and how it compares to other data. Atlas ships exactly that. The point isn't to give an LLM a SQL shell; the point is to give an agent a structured, signed, metered reasoning surface over a dataset it shouldn't have to memorize. That — concretely — is what an AI dataset analysis MCP does in production.

So why build it on top of x402? Because a serious analysis isn't free. Running a profile over 200 columns costs compute, storage, and (sometimes) a downstream API call. We don't believe in flat-rate SaaS for that — we believe in paying per call for what the agent actually consumed. That's the whole premise, and it cascades into the rest of the design.

Five Tools, Priced by Depth

Atlas exposes five paid MCP tools that map to the lifecycle of working with a dataset, plus a handful of free helpers. Pricing scales with what the tool actually has to do, not with how rich the calling agent happens to be.

The paid tier:

• profile_dataset — shape, dtypes, null ratios, cardinality, basic stats. Cheap. Think of it as the first call any sane agent should make before it commits to anything downstream.
• query_dataset — bounded SQL-like or pandas-like filter/aggregate against the source. Priced on row-scan budget, so a WHERE country = 'US' costs less than a full scan over all 4M rows.
• visualize_dataset — returns a chart spec plus a rendered artifact (PNG/SVG) and an anchored reference. More expensive because it pays for chart rendering, image storage on 0G, and the canonicalization step.
• compare_datasets — diffs two datasets on schema, distributions, or row overlap. Costs more because it does the profile work twice and emits a longer evidence package.
• research_dataset — the heavyweight. Enriches the structured findings with public web context and emits an explicit uncertainty section. The most expensive per call, and the one that needs the most careful estimate_cost before pulling the trigger.

The free helpers — atlas_capabilities, validate_dataset_source, estimate_cost, verify_atlas_report, get_artifact — exist so an agent can check what Atlas costs before it spends a cent on a real call. validate_dataset_source rejects inputs we can't actually analyze (encrypted blobs, ambiguous encodings, binary formats masquerading as text). estimate_cost returns the projected 402 amount without committing. verify_atlas_report and get_artifact let an external party re-check a finding's hash and signature without paying — which is exactly what an auditor or a counterparty agent should do.

Deeper analysis costs more because it does more work, full stop. We do not bury that in opaque subscription tiers. Every tool's price lands in the 402 challenge response (accepts[].amount), per the x402 v2 spec, and estimate_cost returns the same number up front for planning. The EVIDIQ docs walk through how payment, settlement, and verification fit together — the mechanics are the same as on the core server, just with a different tool surface. Atlas is, in short, the AI dataset analysis MCP an agent reaches for when it has data and doesn't want to load it.

Why an Agent Should Not Swallow a 2GB CSV

Here's the thing. Most "AI + data" demos quietly load the whole file into the context window and call it analysis. That works at 200 rows. It falls apart at 2GB.

Three reasons it breaks, in priority order:

1. Tokens. A 2GB CSV has tens of millions of cells. Even aggressive sampling blows past any reasonable context window — and even the latest long-context models degrade on structured data past a point.
2. Latency. Pulling that many tokens through a chat-style interface, then waiting for the model to actually look at them, is slow in a way that breaks tight agent loops.
3. Lossiness. The model compresses. It summarizes. It quietly drops "uninteresting" rows — which, statistically, are often exactly the rows your analysis needs most.

Atlas sidesteps all three by never asking the agent to ingest. The agent calls profile_dataset, gets back a structured summary, and reasons over that. A concrete profile_dataset response looks roughly like:

{
  "dataset_id": "ds_8b3a...",
  "rows": 4120503,
  "columns": 28,
  "dtypes": {"order_id":"int64","country":"category",...},
  "null_ratios": {"coupon_code":0.83,"phone":0.41},
  "cardinality": {"country":174,"sku":4120503},
  "anchor": "0g://tx/0x..."
}

The agent now knows it's looking at ~4M orders, has a near-empty coupon column it can safely ignore, and a SKU column that's effectively a row ID. None of that knowledge cost a gigabyte of context. When it needs to drill down, it calls query_dataset with a bounded filter — paying only for what that specific question cost to answer, with the artifact signed and stored so the result is reusable across the agent loop.

We've watched agents try the load-the-whole-thing approach fail on customer data, on log files, and on synthetic benchmarks. The AI dataset analysis MCP pattern beats pass-the-blob, every time. And — this matters — when the agent eventually cites a finding in conversation with a human, the structured Atlas report is the artifact that human can audit. There is no "trust me, the context window said so."

Verifiable Analysis, Not a Black Box

The other quiet nightmare in automated dataset analysis is provenance. Two analysts run "the same" query and get subtly different numbers. An LLM-based analyst is even worse: the same prompt can produce slightly different outputs across runs, and there's no audit trail you can show a regulator or a counterparty.

Atlas treats this the same way the rest of EVIDIQ does: deterministic where possible, signed where it isn't. We figured that if we're going to charge for analysis, we should also be able to prove the analysis actually happened, on the inputs the caller provided, with the steps we say we ran. That's not a marketing line; it's a load-bearing property of the report.

Every Atlas report carries:

• A canonical JSON serialization of the structured finding.
• A keccak256 hash of that canonical form.
• A 0G Storage anchor (mainnet transaction) for the evidence package.
• An optional AI risk analysis run on 0G Compute inside a TEE, recording the provider address and request id.
• An EIP-191 signature under the EVIDIQ publishing key.

What makes the signature bite — in a good way — is the recovery path: anyone — agent, owner, auditor, a counterparty six months from now — can fetch the artifact, re-hash the canonical form, recover the signer, and verify the chain. None of this is theoretical plumbing on our end; the same evidence model backs the EVIDIQ Sentinel docs for trust scoring and the EVIDIQ Notary docs for signed attestations. Atlas is the AI dataset analysis MCP sibling of that family, sharing the same canonicalization, the same anchoring layer, and the same key-recovery flow.

The practical consequence shows up the first time someone disputes a result. When an agent says "I analyzed dataset X and found Y," the human on the other side does not have to take the agent's word for it. They hit verify_atlas_report, get back the canonical hash, the on-chain anchor tx, and the recovered signer address, and decide for themselves whether to accept the finding. That's the same path verify_agent exposes on the core EVIDIQ MCP — verifier-friendly by default, trust-me-not required.

If you're wiring Atlas into a multi-agent workflow where one agent analyzes data and another acts on the finding, the EVIDIQ Operator docs cover how to stitch signed Atlas reports into EVIDIQ's broader agent-trust pipeline — the same way you'd chain a verify_agent call after a payment, but anchored on a data artifact instead of an identity claim.