EVIDIQ Atlas Is the AI Dataset Analysis MCP That Agents Actually Want

Picture an agent that's been handed a 2 gigabyte CSV of customer churn data. It needs to tell its user which segments are bleeding fastest, but it can't open the file — the context window is too small, the per-token cost is too high, and the latency would be embarrassing. So it punts, or it hallucinates a summary that the user has no way to verify. We built EVIDIQ Atlas so it doesn't have to.

What Is a Dataset-Analysis MCP?

An AI dataset analysis MCP is a remote server that lets an agent profile, query, visualize, compare, and research datasets through paid tool calls instead of loading raw rows into its context. EVIDIQ Atlas returns structured findings and signed artifacts, so the agent reasons over summaries, not millions of cells. Metered per call via x402.

A dataset-analysis MCP, in plain terms, is a remote server your agent talks to when it needs to understand data instead of staring at it. The MCP part is the Model Context Protocol — a standardized way for an agent to discover tools, send structured inputs, and receive structured outputs over a normal HTTP connection. The dataset-analysis part is the specialization: every tool on the server exists to operate on tabular data, not to chat, not to summarize a PDF, not to scrape a webpage.

We treat EVIDIQ Atlas as one slot in a wider trust surface. The same x402 payment rails that meter our Sentinel probes and Operator queries meter Atlas calls too. Same scheme — exact, EIP-3009 transferWithAuthorization, settled on X Layer in USDT0. Same signed-evidence model on the back end. Same open-source ethos on the front. If you've already wired an MCP client to evidiq.dev/mcp, Atlas lives behind that same door — different tools, identical contract.

What does an Atlas response actually look like? Not a wall of text. A JSON artifact with a deterministic hash, an on-chain anchor, and a signature the caller can verify against our published key. We'll dig into verification below. For now, the takeaway: the agent pays per call, gets a structured result, and never has to load your dataframe into its own context.

Five Tools, Priced by Depth

EVIDIQ Atlas exposes five paid tools and a handful of free helpers. The paid tools are where the work happens, and the prices scale with how much they actually do:

1. profile_dataset — the cheapest entry point. Atlas fetches a few rows, infers schema, computes basic stats (null counts, uniques, distribution hints) and returns a tight sketch. Cheap because it doesn't touch heavy compute.
2. query_dataset — natural-language or SQL-shaped question over the data. More expensive because the work scales with the dataset and the model behind it has to plan, execute, and verify the query before responding.
3. visualize_dataset — generates charts and saves them as artifacts. You pay for the rendering and the storage anchor on top of the analysis itself.
4. compare_datasets — two or more files, side by side. Drift detection, distribution deltas, schema diffs. Compute roughly doubles, price roughly doubles, contract stays identical.
5. research_dataset — the heavyweight. Combines profiling, querying, and external context into a written report. This is the one an agent calls when the user asks "what's actually going on in this file?"

Deeper analysis costs more because the work is heavier, the latency is longer, and the agent is paying for an artifact that will live on chain. We price depth honestly — that's the only way a meter means anything. If you want a quote before committing USDT0, the free helper estimate_cost will dry-run a request and tell you what the call would cost. validate_dataset_source checks that the URL you handed over is actually reachable, so you don't pay to analyze a dead link.

The free helpers — atlas_capabilities, validate_dataset_source, estimate_cost, verify_atlas_report, get_artifact — exist for one reason: keep cheap, read-only operations cheap. Verifying a report is just a hash and a signature check — there's no model behind it, so we don't charge for it. We want every developer to be able to audit what we did without a budget conversation.

Why an Agent Should Not Swallow a 2GB CSV

There's a meme in agent engineering: "just dump the file into context." It works for 200KB. It breaks for 2GB. Three concrete reasons:

• Token cost. A 2GB CSV is hundreds of millions of tokens at minimum. Even a frontier model will charge you mid-five-figures for a single ingest, and you don't get any structured reasoning back — you get a fuzzy impression.
• Latency. Long-context attention is roughly O(n²) in many implementations, and most agent loops will time out long before they finish reading.
• Fidelity. Models truncate, paraphrase, and forget. The middle of a long context is the most lossy region. Ask an agent to quote row 1,847,503 of a CSV it claims to have "read" and you'll see what I mean.

Atlas sidesteps all three. The agent hands Atlas a URL or a pointer, Atlas does the reading on its own compute, and the agent receives a tight JSON result with the answer it actually needed. Smaller context, smaller bill, lower latency, higher fidelity — and a signed artifact the agent can hand back to its user. That's the core pitch of any AI dataset analysis MCP: keep the agent small, push the data work somewhere with the budget for it.

Quick worked example. An agent receives: "Find the top three churn drivers in our customer table." It calls profile_dataset first to confirm schema, then query_dataset with a few correlated questions, then research_dataset for a synthesized report. Three calls, three x402 payments, three signed artifacts — total cost in cents, total latency in seconds, and the agent never held a single row in its own context window.

Verifiable Analysis, Not a Black Box

Here's the thing we care about most: when an agent's answer is downstream of an external tool, the user needs a way to check the work. We don't want Atlas to be a black box any more than we want Sentinel to be one.

Every Atlas report follows the same evidence recipe as the rest of our stack:

• The artifact is canonicalized (sorted keys, stable encoding) and hashed with keccak256.
• The canonical hash is written to 0G Storage mainnet, returning an on-chain transaction the caller can independently confirm.
• The artifact is then signed with the EVIDIQ key using EIP-191 personal-sign over the canonical hash.
• The signed payload, the storage proof, and the original artifact all live at independent URLs. An auditor, a regulator, or a curious developer can re-derive every byte.

This isn't unique to Atlas — it's the same model behind the EVIDIQ Sentinel docs probes and the EVIDIQ Operator docs workflows. Our EVIDIQ Notary docs walk through the canonical pipeline end to end. The reason we keep reusing the same shape: trust is a property of a system, not a feature bolted onto one tool.

Where Atlas fits specifically in the dataset analysis MCP landscape: when an agent reasons over data it doesn't own, the user deserves to know which data, which computation, and which model produced the verdict. Atlas hands them exactly that. The output is deterministic given the inputs — same dataset, same query, same tool, same artifact bytes — so reproducibility is the default, not an afterthought.

If you want a deeper walkthrough of the trust surface Atlas sits on, the EVIDIQ docs and the main EVIDIQ site collect all of it in one place. We update them whenever the protocol changes, which is rare because we try hard not to change it.