TLDR
AI agents need two different data surfaces from the software they touch, and they map cleanly onto a distinction databases settled decades ago:
- MCP is the transactional (OLTP) surface. It is excellent for point lookups and actions: fetch one record, check one status, create or update one entity. Ship one.
- Data exports are the analytical (OLAP) surface. Aggregates, trends, joins, and anything that scans a whole table belong in the customer’s data warehouse, where an agent answers them with one SQL query. Ship these too.
Routing analytical questions through MCP tool calls is structurally slow, expensive, and error-prone — the data has to pass through the model’s context window, row by paginated row. And because agents ask analytical questions far more often than humans do, agent adoption increases the demand for data exports rather than replacing them.
What MCP is good at
The Model Context Protocol gives AI agents a standard way to discover and call tools exposed by a server. An agent connected to a software vendor’s MCP server can fetch a record, check a configuration, search for an entity, or take an action — each as a tool call whose result is returned as structured content into the model’s context.
For transactional work, this is exactly right:
- “What’s the status of invoice #4521?”
- “Pull up this account’s plan and seat count.”
- “Create a support ticket and assign it to the integrations queue.”
One entity, one small payload, one answer or action. The result is a few hundred tokens the model can actually reason about. Every software vendor with meaningful enterprise usage should expect customers’ agents to want this surface, and should ship it.
The mistake is concluding that because agents can now reach your data through MCP, the data no longer needs to leave your platform. That conclusion fails as soon as the question changes from one row to the whole table.
Where MCP hits a wall: analytical workloads
Consider the same agent asked an analytical question: “Which of our 50,000 users are at churn risk, and how has that trended over the past two quarters?” Four structural problems appear at once.
1. Every row flows through the context window. MCP tool results return to the model as content blocks — even structured results are serialized into text the model reads (spec). There is no spec-level bulk-retrieval path: the protocol’s pagination is cursor-based and defined for discovery operations like tools/list, not for streaming large tool results. Each server improvises its own paging, and every page lands in context.
2. The math doesn’t fit. A user record with usage fields is a few hundred characters of JSON — roughly 100 tokens, with field names repeated on every row.
- 50,000 rows ≈ 5 million tokens: 25× over a 200K context window, and several times over even a 1M window.
- The agent must paginate — 50+ tool calls at 1,000 rows per page — and because each page accumulates in the conversation, the model re-reads everything fetched so far on every subsequent call. Cumulative input grows quadratically with row count.
- At mid-2026 frontier-model prices, a single whole-table question costs tens to hundreds of dollars and takes minutes. The same question against a warehouse is one SQL query: seconds, fractions of a cent.
This is not a controversial observation. Anthropic’s engineering team documented a workflow dropping from 150,000 tokens to 2,000 (a 98.7% reduction) when intermediate data was processed in code instead of flowing through the model’s context, and practitioners report the same scaling wall: returning query results into context works at tens of rows and consumes the entire window by a few thousand.
3. The protocol assumes point-lookup traffic. The MCP specification’s security guidance requires servers to rate-limit tool invocations. A surface that throttles per call is, by design, not a surface for scanning a dataset.
4. The answer is worse, not just slower. A language model hand-aggregating thousands of rows is probabilistic: it miscounts, drops rows, and produces different answers on different runs. A database computing SELECT segment, COUNT(*) ... GROUP BY is exact. For analytical questions, the expensive path is also the unreliable one.
The OLTP/OLAP framework
Data engineering solved this workload split long ago: transactional systems for point reads and writes, analytical systems for scans and aggregates, and nobody runs analytics against the production database. MCP and data exports are the same separation, one layer up:
| MCP (transactional surface) | Data exports (analytical surface) | |
|---|---|---|
| Access pattern | Point lookup, single action | Scan, aggregate, join |
| Typical question | ”What’s the status of invoice #4521?" | "How did churn risk trend this quarter?” |
| Where compute happens | The model’s context window | The customer’s warehouse |
| Latency per question | Seconds per call, minutes when paginating | Seconds for most queries |
| Cost per analytical question | Tens to hundreds of dollars in tokens | Fractions of a cent in warehouse compute |
| Correctness | Probabilistic (LLM aggregation) | Deterministic (SQL) |
| Load lands on | Your API and infrastructure | The customer’s data platform |
| Failure mode | Context overflow, rate limits, token burn | Stale sync (mitigated by frequent syncs) |
The conclusion product teams should draw is not “MCP is overhyped.” It’s that MCP and exports answer different question shapes, and a complete agent-era data access story ships both.
Why agent adoption increases export demand
The case for data exports was already strong — enterprise customers expect your product’s data in their warehouse. Agents raise the stakes for two reasons.
Analytical query volume is exploding. Automated traffic passed human traffic on the web in 2026 — 57.5% of HTTP requests, per Cloudflare — and HUMAN Security’s 2026 State of AI Traffic report measured agentic traffic growing over 7,800% year over year, with software and SaaS among the most-targeted categories. Unlike human analysts, agents ask analytical questions continuously: on every workflow trigger, every monitoring loop, every “summarize what changed” request. If your data is reachable only through your API and MCP server, all of that load lands on your transactional surface — your infrastructure, your rate limits, your customers’ token bills.
The ecosystem’s own answer to “agents doing analytics” is SQL over a warehouse. The warehouse vendors’ MCP integrations have converged on the same architecture: the agent uses MCP to discover schemas and submit a query, and the warehouse does the scan. The agent writes one SELECT statement; the data never passes through the context window. That architecture only works for your customers if your product’s data is in their warehouse — which is precisely what data exports do. In the agent era, exports are not the legacy alternative to MCP. They are the substrate that makes agent analytics on your data possible at all.
What to ship: a decision framework for product teams
The routing rule fits in one line: if the question is about one row, it belongs on MCP; if it’s about the whole table, it belongs on exports.
In practice:
- Ship an MCP server for lookups and actions. Scope it to the transactional question shapes — entity fetches, status checks, searches, writes. Keep payloads small; that’s what the surface is for.
- Ship data exports for everything analytical. Sync your product’s data — events, usage, records, audit logs, outputs — continuously into the customer’s warehouse: Snowflake, BigQuery, Databricks, Redshift, S3, and the rest of the platforms enterprise customers actually use. This is the surface their agents (and their analysts, and their AI platforms) will compute on.
- Treat warehouse-native delivery as the bar. Customer-built API pipelines and third-party ETL tools push the integration burden back onto the customer and hit the same rate-limit ceiling the agents do. Warehouse-native means the connection is part of your product: self-serve setup, high-volume transfer paths, schema evolution, observability.
- Don’t let the MCP roadmap displace the export roadmap. They compete for the same engineering quarter but serve disjoint workloads. If anything, sequence exports first: an MCP server without an analytical surface invites traffic it is structurally unable to serve.
Prequel exists for step 2 and 3: it’s the API purpose-built for product and engineering teams shipping warehouse-native data exports (and imports) as a product feature, across every major warehouse, lake, and object store.
For the opinionated version of this argument, see the companion post: Some Questions Don’t Fit in a Context Window
FAQs
Can’t we just put our existing API behind an MCP server and call it done? For transactional questions, yes — that’s a fine starting point. But it inherits everything that makes APIs wrong for analytics: pagination, rate limits, row-by-row transfer. Wrapping an API in MCP changes who calls it, not what it’s good at.
Won’t bigger context windows fix this? They move the cliff; they don’t remove it. Context windows grow linearly while per-token costs stay roughly proportional, and the quadratic accumulation of paginated results outpaces both. Even a dataset that technically fits is still being aggregated by a probabilistic model instead of a database — slower, costlier, and less accurate than SQL at any window size.
Is MCP a replacement for our API or our exports? Neither. MCP is a new consumption layer for the transactional surface — a standard way for agents to do what your API already does. Exports remain the analytical surface. The three coexist: API for programmatic integrations, MCP for agent lookups and actions, exports for whole-table data access.
What about agents querying the warehouse directly through a warehouse MCP server? That’s exactly the architecture this guide recommends — and it’s the strongest argument for exports. A warehouse MCP server lets the agent write SQL while the warehouse does the scan, but it can only query data that’s already there. Your export pipeline is what puts your product’s data within reach.
Do data exports need to be real-time for agents? Rarely. Most analytical questions tolerate minutes of staleness, and frequent incremental syncs cover the rest. The transactional questions that genuinely need live state — “what’s the status right now?” — are point lookups, which is what your MCP server is for. The two surfaces cover each other’s gaps.
