MCP Solved the Integration Problem. Now the Data Problem Is Exposed.

The scenario used to go like this. A company runs a promising AI pilot. The demo works. The model can answer questions about customers, pull numbers from the warehouse, generate the kind of summary that makes executives lean forward. Then someone asks: can we connect this to our actual production data?

The answer is technically yes. The practical answer is: put in a ticket, and we'll scope it after Q3 planning.

That integration step (connecting an AI model to a live internal system) used to require custom code for every connection. Your warehouse needed one connector. Your CRM needed a different one. Your internal wiki needed another. Each was a small engineering project, none were glamorous, and all competed with everything the data team was already behind on. AI pilots sat in demo purgatory not because the AI wasn't good enough, but because the pipeline work never got resourced.

That specific problem is now largely solved.

What MCP Actually Does

The Model Context Protocol, published by Anthropic in late 2024, is an open standard that defines how AI models and external systems talk to each other.

The basic architecture has three pieces. Servers expose data and capabilities from a specific system: your database, your CRM, your file system, your internal documentation. Clients are the AI models or applications that consume those servers. Tools and resources are the specific things a server can do or return, whether that's running a query, fetching a document, or calling an API endpoint.

The analogy that actually helps: USB. Before USB, every peripheral had its own connector and its own driver. You couldn't just plug things in. USB created a common standard, and suddenly hardware stopped being the constraint. MCP is attempting to do the same thing for AI integrations. Instead of writing a custom connector for every system, you drop a server configuration and the AI knows how to use it.

What used to take weeks of engineering work now takes hours of configuration. That is a meaningful shift.

The Bottleneck Moved

Here is where the conversation about AI strategy tends to lose the thread.

The integration problem got easier. That doesn't mean the AI problem got easier. It means the hard part changed.

When an AI agent can now connect to your data warehouse with relatively low friction, the question is no longer whether you can make that connection. It becomes “what does the AI find when it gets there?”

Imagine every instrument in an orchestra is now wired into the same sound system. The connection problem is solved. But if every musician brought a different version of the score or plays at the same level, you don't get music; You get confident noise.

That is a reasonable description of what happens when a properly configured AI agent queries a warehouse with inconsistent metric definitions, undocumented field names, and four different tables that all claim to be the source of truth for revenue.

The failure mode is specific and worth naming. The AI doesn't tell you it's confused. It gives you an answer. The answer is coherent, formatted, and wrong in ways that are hard to catch unless you already know what the right answer should be. That is a worse outcome than no answer at all.

Four Questions to Ask Before You Build

This isn't an argument to slow down or wait for perfect conditions. It's an argument for doing the diagnostic work before you build so that what you build is trustworthy.

Four places to start.

Can you define your key metrics in one sentence, and would everyone in the room agree?

Usually, when they can't, the problem isn't really the metric. It's the entity underneath it. Sales, finance, and your data team define ARR differently because they've never agreed on what a customer is at the model level. An AI querying that ambiguity doesn't reconcile it. It picks a version and reports confidently. Before you align on metric definitions, ask why they disagree. The answer almost always lives in how the data model represents the underlying entity, not in the formula itself.

Does your warehouse have documentation that a system could actually read?

Not the documentation someone wrote in 2021 that lives in a Confluence page nobody visits. Inline field descriptions, consistent naming, a data dictionary with enough context that a language model can distinguish cust_id_v2 from customer_id_final_use_this_one. If a new analyst would struggle to orient themselves in your data, an AI agent will too.

Do you have a semantic layer? Tools like dbt's metrics layer, TextQL, and Sigma translate raw warehouse tables into business concepts. AI agents reason much more reliably when there's a defined translation layer between a SQL query and what ARR actually means to your business. If you don't have one, building it now pays off regardless of AI.

What happens when you ask your AI tool the questions your executives are already asking? Run the test before you commit to anything. The failure modes you find will tell you exactly where the data model needs attention. The goal isn't perfect data. It's knowing specifically what is imperfect before the AI surfaces it as someone else's problem.

When those four questions are hard to answer, they tend to share a root. The metrics disagree because the entities underneath them were never resolved. The documentation is thin because nobody agreed on what the fundamental objects in the system are, or how they relate. The semantic layer is missing for the same reason there's no single canonical version of a customer, a deal, or a product to build from. Most data readiness problems, looked at closely enough, are relationship problems first. The data usually exists somewhere. What's missing is a clear model of what the core things are and how they connect.

That's why the most durable fix isn't metric alignment or documentation, as useful as both are. It's building validation into the architecture at the point where data enters, not at the point where a report discovers it's wrong. Catch the inconsistency at the source, and everything downstream inherits the integrity instead of the problem.

The Work That Remains

The companies that get lasting value from AI on their own data aren't necessarily the ones who moved fastest to integrate it. They're the ones whose data was ready when integration became easy.

That readiness isn't a technology question. It's a modeling question, a governance question, a question about whether the people who built your warehouse and the people who need answers from it have ever been in the same room. MCP made the connection cheap. It didn't make the underlying data trustworthy.

That part is still the work. Done right, trust stops being something a team re-earns every reporting cycle. It becomes a property of the architecture, not a feeling. Built in upstream, inherited by every query, dashboard, and AI response that draws from it. That's when the connection is actually worth having.