MCP Isn't a Warehouse. Don't Sell It as One.

"Why do we need Databricks or Snowflake at all? Can't you just MCP into HubSpot, Salesforce, and NetSuite and answer my questions directly?"

Three CDOs asked me the same question last month, unprompted. I love this question as anyone asking it has stopped treating the data stack as furniture and started asking why each layer earns its budget, which is exactly what a CDO should be doing in 2026.

On the surface, the question imagines a beautiful world: no ETL, no pipelines, no warehouse bill, just an agent and a protocol. Every big simplification in computing started with a question shaped like this one. The cloud began with "why do we rack our own servers?" SaaS began with "why do we install software at all?"

Let’s take the question apart properly, and let the physics make the case.

The physics stays put when you change the protocol

Our article on catalogs traced how insight production flows: data leaves OLTP systems, moves through analytical layers, and lands in BI. It made the case that transactional systems and analytical systems have to be physically separate with different storage layouts, different indexes, and different compute profiles.

A quick overview of MCP (Model Context Protocol)

MCP is a smart, modern protocol, designed by Anthropic, to talk to a transactional system. It’s a universal way to connect AI systems to tools and data sources.

‍

A protocol doesn’t change the purpose of the system underneath. Wrapping an OLTP system in MCP doesn't turn it into a columnar analytical store.

A sneak peek into the world of OLTP, OLAP, and messy data

Storage is row-oriented, so one complete record can be written or fetched in a single touch. When you ask an analytical question, "summarize revenue by segment across three years", the response requires touching every customer, every order, every month. You need a full scan running against a machine engineered to touch one row at a time.

The row layout carries a second cost: messy data. Transactional systems are write-optimized, so data lands in whatever shape the app needed at that millisecond, with duplicate entries, free-text fields, and codes that vary by team. Even if MCP fetches those rows, cleanup and standardization still have to happen somewhere so that AI can reason over trusted data.

None of this requires you to haul everything into a single monolithic warehouse. Federate across as many analytical sinks as your topology needs: a lakehouse, a warehouse, or an engine querying both.

The real distinction is OLTP vs. OLAP. One side represents systems of records that are write-optimized and holding current state. The other side is where systems built to answer business questions sit, read-optimized and holding every state of a record over time.

Where your analytical data lives, across how many systems and from which vendors, is a topology choice you get to make freely. Which side of the line a question runs against is a choice you never get, because every business question about history is an OLAP workload, and no protocol rewires that.

Bringing data to a columnar, analytical layer, cleaned and standardized on the way in, is what makes AI insight possible at enterprise scale. Skip that step and you are fighting the physics, and the physics is undefeated.

The two primary limitations of MCP

1. MCP exposes a sliver of what analytics needs

An MCP into a SaaS system surfaces exactly what the vendor chose to publish. For example, HubSpot’s MCP can tell you "who did we add this week: contacts, deals, tickets, and engagements."

This interface cannot answer "which segment shows the highest LTV over 24 months." Answering such a question requires joining contacts to orders to support history, across systems, over two years of data.  

2. You inherit the transactional system's limits

Every MCP call lands on the production system, so it inherits that system's rate limits, latency, and access controls.

An agent asking a hundred questions gets throttled; an agent asking a thousand becomes an incident.

Teams have already run this experiment. The results are in.

Last year, several companies wired an agent straight into a source system's MCP to answer business questions. Each one hit the same two walls in production: first answers the API could not express, then throttling once question volume grew.

Both map directly to the structural problems discussed above. a16z reached a compatible conclusion from the other direction: data agents are essentially useless without the right context, and context does not live inside a transactional API.

Long story short: this isn't a tooling problem waiting to be patched, it's the physics.

So, what IS MCP actually good for?

MCP shines for live, on-demand reach. The moment a question arrives and the answer needs to be fresher than any batch load, MCP fills gaps a warehouse:

1. Need to know a specific customer's current status in the source system, right now? MCP call.

2. Need to trigger an action back in the source system? MCP call.

3. Need to summarize three years of behavior across every source in the enterprise? Warehouse.

Each serves a distinct purpose.

An MCP call answers "what is true about this one thing, right now," so it optimizes for freshness and reach: one record, straight from the source, at the moment of the question. A warehouse query answers "what has been true across everything, over time," so it optimizes for memory and scale: millions of rows, reshaped for scanning, holding history the sources overwrote long ago.

Neither mechanism can serve the other's purpose. A platform built for the agentic era knows which purpose a question carries before it chooses how to answer.

A modern data platform is both MCP server and MCP client

The architectural stance for the agentic era has two halves, and a platform needs both.

As an MCP server, the platform publishes its trusted analytical answers outward, so downstream agents, Slack, and Copilot consume governed numbers instead of guessing against raw tables. WALT's Reasoner already works this way, serving the data context graph and its deterministic answers to any MCP-compatible consumer. Same question, same answer, every time.

As an MCP client, it reaches into external systems when a question calls for live truth, and returns to governed history for everything else. Your engineers keep supplying intent and judgment; the plumbing between protocols stops eating up all of their time.

Notice what this stance costs you: zero new tools on the stack diagram. The platform you already own becomes a well-behaved citizen of the agent infrastructure you are already building.

The wrong mental model: MCP as ingestion

It’s tempting to say "MCP is just another way to bring data in." Resist that urge as it’s trying to blur boundaries where it shouldn’t.

Bringing data in for analytics means bulk, incremental, replayable, full historical fidelity, and that requires columnar storage and a warehouse. An MCP call at question time is live, capability-limited, rate-limited, one record at a time, which describes a lookup rather than a pipeline.

A lookup and a pipeline belong to different categories. Treating them as one category is precisely what produced the failures above.

What should CDOs expect from MCP

Can you skip the warehouse by MCPing into your source systems? No, and anyone selling you that plan is selling against the physics of it all.

But yes, you can expect your data platform to natively speak MCP. This means consuming external MCPs when the question calls for it, and publishing MCPs so that agents and downstream applications can consume the platform's trusted answers.  

That is a very different platform decision than "add MCP to the pipeline." Get the distinction right and the roadmap gets simple.

MCP doesn’t spell the end of the warehouse. Instead, it solves access, connecting the warehouse to every agent in the enterprise and every agent to its sources.

How does WALT help with answering the business questions

Access was never the scarce ingredient: an agent holding a fistful of records still has no idea what "revenue" means in your business, which of the five versions to trust, or how the entities connect.

That missing meaning is exactly what WALT supplies. WALT’s data context graph carries the ontology, the canonical metric definitions, and the entity relationships, so every answer served over MCP is reasoned deterministically instead of guessed.

A graph is only as good as the data underneath it, which is the second way WALT helps. WALT’s crew of autonomous data engineers ingests, transforms, analyzes, and governs high-quality data. No new tool on your stack diagram, and no bet against your engineers; grunt work moves to agents, judgment stays human.

If you want to see a continuously maintained data context graph served over MCP, on top of the stack you already own, see how WALT works, or book a demo

Sources

Model Context Protocol

Introducing the Model Context Protocol | Anthropic

What is a data lakehouse? | Microsoft Learn

What is a data warehouse? | Databricks

OLTP vs OLAP - Difference Between Data Processing Systems | AWS

Your Data Agents Need Context | Andreessen Horowitz