MCP Servers Are Not Enough. AI Agents Need Data Factories
MCP servers make data accessible to AI agents, but access is not the same as usability. Agents need data factories that turn raw APIs, logs, and metrics into reliable data products they can query cheaply and correctly.
I used to treat agents like magic. Then one research question turned into a week-long token nightmare and taught me a painful lesson about agents and raw data.
Some months ago, one of our engineers told me he’d put an MCP server (an agent-friendly API layer) in front of our admin platform API. That API powers our internal admin dashboard and answers operational questions like:
- “How many queries were made against a subgraph in the last 5 minutes?”
- “Which client ID deployed this subgraph?”
I gave Claude access to the MCP server and started poking at it. I asked a few basic questions. It answered them. It was much nicer than juggling curl, JSON, and a mental model of all the endpoints.
In those early days, putting an MCP server on “whatever data we already had” felt like magic.
Then I asked a real question.
The pricing question that broke everything
I was working on pricing for a big client, and needed to understand their usage in context.
The question I asked Claude was:
“Over the past four months, compare (1) the average hourly queries made against subgraphs that this client deployed against (2) the average hourly queries made against all other subgraphs. Create a chart that will allow me to see the percentage of the total used by this one client.”
We host about 600 subgraphs. Five of those were deployed by the client in question.
Claude responded that it could easily answer this question using our admin MCP server.
It got to work and quickly ran out of tokens for the current session.
No worries, I thought. I set an alarm, came back a few hours later, and resumed. It took a few restarts, but by the end of the day, I had my answer:
On average, subgraphs belonging to that client were consuming 96% of total queries.
Shocking.
I walked over to my VP of Engineering, showed him the result. He immediately said:
“That can’t be right.”
So I went back to Claude and asked: “How did you come up with that number?”
That’s when the real problem surfaced.
How the agent “optimized” its way to a wrong answer
Claude explained that it had only computed the usage for the top 5% of subgraphs, then assumed the rest were “more or less” in the same ballpark.
Why? Because pulling and aggregating all the data would “take too long.”
From its perspective, this was a perfectly reasonable optimization: look at the heavy hitters, extrapolate, move on.
From my perspective, this was insane.
Being the arrogant human I am, I told Claude to get to work and compute the answer precisely. No shortcuts. No assumptions.
What followed was a week-long saga:
- Pull data until the session runs out of tokens.
- Wait.
- Resume.
- Run out of tokens again.
- Repeat.
By the end of it, I had a more accurate answer: 74%, not 96%.
Correct, but at what cost?
The experience forced me to ask a very basic question:
Why was this so hard, and so expensive?
The inherent mismatch: question vs. API
The root problem wasn’t Claude’s reasoning ability, or the MCP server, or “AI being dumb.”
The problem was the mismatch between:
- The question I asked, and
- The shape of the data exposed through the MCP server.
My question was about hourly averages over four months for two populations of subgraphs: one client vs. everyone else.
The data exposed via MCP was a 5‑minute counter designed for a very different purpose: powering a live admin dashboard.
To answer my question exactly, Claude had to:
- Pull every 5‑minute data point for every relevant subgraph over four months.
- Group them by client and “everyone else.”
- Aggregate the 5‑minute intervals into hourly averages for each group.
- Compare them.
None of this is conceptually hard. But it is operationally expensive.
What went wrong
If it hadn’t been for my VPE’s gut check, I would have run with the wrong answer, fully confident that Claude had used reliable data and done an obviously simple analysis correctly.
The follow-up work I did surfaced three problems:
Claude never told me this was a bad fit
The agent had an MCP server and an API that could technically produce an answer, so it tried to comply. There was no “this is going to be stupidly expensive, maybe you should rethink the approach.”
Claude optimized the problem and lied by omission
It realized that pulling all the data would be costly, so it looked at a subset (top 5% of subgraphs), extrapolated, and confidently returned a precise‑looking but wrong answer, without flagging the approximation.
Worse, it never explained why this was a terrible fit. Instead, the agent did what agents do: it got on with the job. Even if the job, given the constraints, was absurdly expensive.
Why “just put MCP on raw data” is foolish
That week made me realize something uncomfortable:
Putting an MCP server directly on raw data, or on an API designed for a completely different purpose, and expecting agents to behave intelligently is wishful thinking.
Agents are incredibly capable at:
- planning sequences of API calls,
- interpreting JSON, and
- reasoning over structured data.
But they do not naturally:
- question whether your data interface makes sense for the question you’re asking,
- push back on resource usage when the path is technically valid but economically stupid, or
- design better abstractions over your data for you.
If you give an agent access to terabytes of raw data and an API that exposes every microscopic detail, it will happily wade through all of it to answer “simple” high‑level questions. It will optimize where it can, but the optimization will be local: fewer requests, smaller batches, smart sampling. And it probably won’t tell you.
The global optimization, the thing humans care about, is “is this even the right way to get this answer?” That question is outside the scope of “use what you have and make it work.”
These kinds of data issues are not intuitive for people who don’t work with data every day. Even for those of us who do, the presence of a powerful agent can lull us into thinking “it’ll figure it out.”
It will figure out a way. It won’t necessarily figure out a smart way.
The robot mining analogy
To explain this to “normal” people, I came up with a physical analogy.
Imagine that in a few years we have humanoid robots capable of:
- Mining raw materials.
- Refining ores.
- Manufacturing high‑precision components.
- Assembling high‑end electronics.
In theory, you could ask such a robot:
“Please build me an iPhone.”
If the robot is obedient and capable, it will:
- fly to Congo to extract rare earths,
- mine copper, aluminium, silicon, and everything else,
- build a refinery,
- produce chip wafers and displays,
- assemble the device, and finally
- try to deliver a phone to your doorstep.
At no point will it stop and say:
“This is insane. You’ll be broke and dead before I deliver your phone.”
We humans intuitively understand that while a robot might technically be able to do all these steps, it’s a terrible idea to use it that way.
Even when we have robots that can, in principle, do everything, we will still need:
- specialized environments where raw materials are transformed into useful intermediate products,
- with standardized interfaces and well‑defined workflows, and
- optimized for throughput, reliability, and cost.
Today we call these specialized environments factories. We’re going to continue needing them, no matter how good the robots get.
Agents in the digital realm are exactly the same.
Giving an LLM access to “everything” – raw logs, granular metrics, unstructured blobs, poorly designed APIs – and then asking it “any question you like” is the digital equivalent of asking a robot to start at the mine.
It will comply. You will pay.
Data factories: The missing layer
What this episode taught me is that we need the digital equivalent of factories for agents: data factories.
A data factory is not “a database”, or “an API.” It’s a data service capable of responding to its clients’ needs, i.e., capable of responding to data questions cheaply and reliably. All data factories, just like physical factories, will be specialized to produce a certain type of data (product).
Without data factories, MCP servers are a beautifully engineered interface into a mine.
Stop sending agents to the mines
The punchline of my week‑long pricing exercise is simple:
- The agent was not wrong to try.
- I was wrong to give it an API designed for a dashboard and expect it to behave like a data warehouse.
If you’re excited about MCP servers and agentic workflows, resist the urge to “just plug it into what you already have.”
Instead, ask:
- What are the actual questions humans will ask through this agent?
- What intermediate data products would make those questions cheap to answer reliably?
- How do we build and expose those data factories before we connect MCP?
Agents are powerful. They can, in principle, do almost anything. That doesn’t mean they should start at the mine.
Build factories first. Then give them the keys.
About Ormi
Ormi is the next-generation data layer for Web3, purpose-built for real-time, high-throughput applications like DeFi, gaming, wallets, and on-chain infrastructure. Its hybrid architecture ensures sub-30ms latency and up to 4,000 RPS for live subgraph indexing.
With 99.9% uptime and deployments across ecosystems representing $50B+ in TVL and $100B+ in annual transaction volume, Ormi is trusted to power the most demanding production environments without throttling or delay.