Meet EVIDIQ Atlas: Our AI Dataset Analysis MCP, Billed Per Call

Picture this: a coding agent is debugging a customer's flaky analytics pipeline. The user pastes a 1.8GB CSV of weekly events and asks the agent to "find the anomaly." The agent, dutifully, starts reading rows. By token 40 it has lost the header. By token 200 it is hallucinating column names. By the time you see the reply, you have paid for a confused model that produced nothing useful.

That is the failure mode EVIDIQ Atlas was built for.

What Is a Dataset-Analysis MCP?

EVIDIQ Atlas is an AI dataset analysis MCP — a Model Context Protocol server that exposes tools for profiling, querying, visualizing, comparing, and researching datasets on demand. Instead of loading raw rows into the agent's context window, the agent calls Atlas and receives structured findings, charts, and signed artifacts it can actually reason over.

Most agents today handle data the way they handle text: paste it in, hope the model stays coherent, and pray nothing important lives past token 8,000. That works for a 12-row toy table. It collapses the moment a real dataset shows up. A proper AI dataset analysis MCP flips the model — the agent does not see the bytes, it sees answers.

In practice, that means an agent sends a dataset reference (URI, signed URL, or on-chain content id) to Atlas, picks a tool, and gets back JSON, a chart spec, or a signed report. The agent never has to ingest a 2GB CSV. It reasons over a 4KB summary that a deterministic pipeline produced. If the summary is wrong, the data was wrong — and Atlas tells you exactly which.

We designed Atlas to slot into the same MCP wiring the rest of EVIDIQ docs describe: install the skill at evidiq.dev/skill.md, point your client at the Atlas MCP server, and your existing tool-calling loop gains five new verbs for working with data.

Five Tools, Priced by Depth

Atlas ships with five paid analysis tools and a set of free helpers. Every paid call is settled in USDT0 over X Layer via the x402 protocol — HTTP 402 with accepts[].amount, EIP-3009 transferWithAuthorization, no subscriptions, no API keys to babysit. The pay-per-call shape is deliberate: shallow reads cost almost nothing, deep synthesis costs real money, and the price is on the wire before you commit.

The paid tools, in order of how much they actually do:

• profile_dataset — schema, row count, missingness, type inference, basic stats. The cheapest tier, because it scans once and stops.
• query_dataset — runs a bounded query (SQL or filter expression) and returns rows plus an aggregate summary. Costs more because the server executes and re-aggregates.
• visualize_dataset — produces a chart spec (Chart.js / Vega-Lite shape) plus the underlying aggregation. The most expensive read tier, because the server has to compute the bins.
• compare_datasets — diffs two datasets on schema, distribution, or join keys. Higher still, because the cost is roughly double a single profile.
• research_dataset — the heavy one. Pulls public sources, cross-references the dataset against external references, and returns a citation-backed writeup. Most expensive, because the server runs an external retrieval pass.

The price ladder is not an accident. A profile is a cheap sanity check. A research call is a small piece of analyst labor. We price them so an agent that only ever needs profile_dataset pays pennies, while an agent that genuinely needs synthesis pays for the work — same shape as how EVIDIQ Sentinel docs price verify_agent against the depth of the probe.

The free helpers matter just as much, and they are the ones we expect agents to call first:

1. atlas_capabilities — lists what Atlas can do right now, including tool prices and any rate-limit notes. Call this once per session.
2. validate_dataset_source — checks that a URL, CID, or signed handle is reachable and the bytes match a declared hash before the agent commits a paid call.
3. estimate_cost — given a proposed query or tool, returns the expected x402 price so the agent can ask the user before paying.
4. verify_atlas_report — re-fetches a report's evidence from 0G Storage, re-hashes it, and recovers the EVIDIQ signer. Independent verification, no trust-by-default.
5. get_artifact — pulls a chart, a CSV, or a summary blob by artifact id, so the agent can hand concrete deliverables to a human or another tool.

The "estimate first, pay second" pattern is the same one we use across the rest of EVIDIQ: never let an agent spend money it cannot justify, and never make a paid call on a dead URL.

[IMAGE_PROMPT: A flat technical illustration showing a stylized MCP server box on the left connecting via five labeled cable pipes (profile, query, visualize, compare, research) to a stacked chart panel on the right, with x402 coin tokens floating along each pipe, developer terminal aesthetic, muted teal and slate palette, soft grid background, no logos or readable text]

Why an Agent Should Not Swallow a 2GB CSV

Three reasons, in order of how badly they hurt:

1. Context cost. A 2GB CSV at roughly 50 bytes per row is about 40 million rows. Even compressed as a sample into the agent's context window, it crowds out the system prompt and forces the model to either truncate or summarize and lose precision.
2. Token cost. You are billed per token in. Reading 200k tokens of raw data to answer one distributional question is the most expensive way to do it wrong.
3. Fidelity cost. A model summarizing rows will quietly invent column semantics. The summary looks fluent and is wrong. You ship it. You find out at 3am.

Here is what an Atlas call looks like instead. The agent sends:

{
  "tool": "profile_dataset",
  "source": "ipfs://bafy.../events-2026-q1.csv",
  "options": { "sample_rows": 5000, "include_histograms": true }
}

Atlas returns:

{
  "schema": { "user_id": "string", "event_ts": "datetime", "value": "float" },
  "row_count": 12473821,
  "missingness": { "value": 0.0023 },
  "anomalies": [{ "column": "value", "kind": "long_tail", "p99": 412.0, "p999": 9821.0 }],
  "report_hash": "0x9f3c...e1"
}

The agent now has, in roughly 400 tokens, a correct, signed picture of the dataset. It can answer "what does this look like" without ever loading the bytes. If the user wants the long tail visualized, the agent calls visualize_dataset next — still no raw rows in context, still a tiny footprint.

This is also why we wired validate_dataset_source as a free call. We have watched agents hit a stale URL, fail to read the bytes, and then call query_dataset against an empty stream — paying for a useless answer. Validate first, pay second. The math is simple: a free validation that catches a dead source saves you a paid query that returns nothing.

Verifiable Analysis, Not a Black Box

A response from a closed-source analytics API is a vibe. A response from Atlas is a piece of evidence.

Every Atlas report is built on the same evidence pipeline we use across the rest of the platform:

• The canonical report JSON is hashed with keccak256.
• The hash, the source reference, and the raw evidence are anchored on 0G Storage mainnet, which returns an on-chain transaction anyone can look up.
• An optional AI risk-analysis pass runs on 0G Compute with GLM-5.2 inside a TEE; the compute provider address and request id are recorded into the evidence bundle.
• The final verdict is signed with the EVIDIQ key using EIP-191.

Anyone — the agent, the user, a competing verifier — can call verify_atlas_report to re-fetch the evidence, re-hash it, and recover the signer. Same inputs, same hash, same signature. If the bytes move, the verification fails loudly. This is the exact same evidence model our EVIDIQ Notary docs describe for trust reports, and it is what lets an AI dataset analysis MCP be trusted in adversarial settings.

Here is the practical consequence: when an Atlas report says "the p99 of value is 412," that number is reproducible, auditable, and tied to a specific dataset hash on 0G Storage. If your agent later acts on it — triggering a refund, flagging a fraud pattern, blocking a deployment — the audit trail is already there. You are not arguing with a model about a hallucinated stat; you are pointing at a signed receipt.

The same shared backbone is what makes Atlas, Sentinel, and the verify_agent endpoint feel like one product instead of three. Whether you are checking an agent's identity, attesting to a piece of data, or pulling a structured finding out of a CSV, the evidence format is identical and the verification path is identical. Honest take: deterministic profile outputs are easy to verify, but visualizations and research calls involve model calls that are not byte-identical between runs. For those, the evidence bundle captures the model id, the provider address, and the request id, and the verifier flags any mismatch between declared and actual inputs. The pipeline is honest about where determinism stops.

[IMAGE_PROMPT: A flat illustration of a sealed envelope on the left labeled "report" transforming into a layered verification stack on the right — keccak hash, 0G Storage anchor chip, TEE compute badge, EIP-191 signature stamp — connected by an arrow, slate and teal palette, soft shadows, subtle blockchain grid background, no logos or readable text]