Do You Need a Semantic Layer for MCP AI Agents on Your Data Warehouse?
What a raw warehouse MCP server gives an agent, what it leaves out, and when governed metrics become necessary
Yes, for any question that involves a business metric, an MCP server on a raw warehouse is not enough context, and a semantic layer (or an equivalent governed metric definition) closes the gap. Cube argues in 2026 that agents have to guess whether "revenue" is gross or net unless metrics are governed. MCP gives the agent a way to call the warehouse. It does not tell the agent what your numbers mean.
Key Takeaways
- •A warehouse MCP server standardizes how an agent connects and runs queries; it does not define metrics, grain, or business rules.
- •Without governed metrics, an agent picks a definition of "revenue" or "active customer" on its own, and the answer can be wrong while still looking plausible.
- •A semantic layer gives the agent one named, versioned definition per metric, so the same question returns the same number every time.
- •Raw MCP access is acceptable for schema exploration, lineage questions, and one-off analysis where a human reviews the SQL.
- •The strongest setup stacks three things: MCP for transport, a semantic layer for metrics, and a catalog for ownership, freshness, and policy.
What an MCP server on a raw warehouse actually gives an agent
The Model Context Protocol is a transport and tool-calling standard. The MCP specification, revision 2025-06-18, defines how a client discovers a server's tools, resources, and prompts and how it invokes them. That is a real benefit: one connection pattern works across Claude Code, Cursor, Windsurf, VS Code, and any other MCP-compatible client, so you stop writing a custom integration per tool.
What the protocol standardizes is the shape of the call, not the meaning of the data behind it. A typical warehouse MCP server exposes tools such as list tables, describe a table, and run a read-only query. The agent receives column names and types, maybe a table comment, and a result set. Everything else about what those columns mean has to be inferred from names like amt, status, or created_at.
That inference is where trouble starts. Column names are a weak signal. A column called revenue might be gross bookings in one table and recognized revenue net of refunds in another, and both are valid in their own context. The agent has no way to tell which one the person asking had in mind, so it chooses, and it usually chooses without telling anyone.
There is also the question of what the server leaves out on purpose. Read-only credentials, row limits, and timeouts are sensible defaults, and we recommend them. But they are safety controls, not meaning controls. A query can be safe to run and still answer the wrong question, and no amount of connection hardening changes that.
Where raw warehouse access breaks down for business questions
Consider the question "what was revenue last quarter?" A human analyst asks three clarifying questions before writing SQL: gross or net, booked or recognized, and in which currency. An agent connected to a raw warehouse usually skips those questions. It scans table names, finds something plausible, writes a query, and returns a number with full confidence in its tone.
The failure is quiet because the SQL is valid. It runs, it returns rows, and the figure is in a believable range. Nobody sees a stack trace. The error only surfaces when a finance lead notices the number disagrees with the board deck, and by then the agent's answer may already have been pasted into a planning document.
Three recurring problems show up in our conversations with data teams. Metric ambiguity means two reasonable definitions exist and the agent picks one. Grain mismatch means the agent joins an order-level table to a customer-level table and double-counts. Stale or deprecated tables means the agent finds a table that was correct two years ago and still sits in the schema. A column comment rarely fixes any of these.
None of this is unique to agents. Human analysts hit the same walls, which is why semantic layers existed long before MCP. What changes with agents is volume and trust. An agent answers hundreds of questions a day, and each answer reads as authoritative, so a small definitional error spreads further than one analyst's mistake would.
What a semantic layer adds on top of MCP
A semantic layer is a governed set of definitions: metrics, dimensions, entities, and the joins between them. The dbt documentation describes MetricFlow as the engine that lets you define metrics once in code and query them consistently, generating the SQL for the right grain and joins. The definition lives in version control, so a change to "net revenue" is a reviewed commit rather than a quiet edit in someone's notebook.
For an agent, the effect is a change in what it is allowed to ask. Instead of writing free-form SQL against raw tables, it requests a named metric, grouped by named dimensions, over a time range. The layer compiles that request into SQL. The agent no longer decides what "revenue" means; it decides which governed metric matches the question, which is a much smaller and more checkable choice.
This is already how some MCP servers for analytics work. The dbt-mcp package on PyPI packages dbt's capabilities as an MCP server, including access to semantic layer metrics, so a client such as Claude Code or Cursor can query governed definitions through the same protocol it uses for everything else. The transport stays the same; the content behind it changes.
A semantic layer also gives you something raw access cannot: an audit trail for meaning. When two dashboards disagree, you can point at the metric definition and its history. When an agent's answer is challenged, you can show which metric it used. That makes agent output reviewable by people who do not read SQL.
Raw MCP access versus a semantic layer, side by side
| Dimension | Raw warehouse MCP server | MCP plus semantic layer |
|---|---|---|
| Metric definitions | Inferred by the agent from column names | Defined once, versioned, and named |
| Same question, same answer | Not guaranteed; varies by prompt and model | Consistent; metric compiles to the same SQL |
| Join and grain handling | Agent writes joins and can double-count | Layer resolves entities and grain |
| Schema exploration | Strong; agent can list and describe anything | Limited to modeled entities unless paired with a catalog |
| Ad hoc, long-tail questions | Flexible; any table is reachable | Constrained to what has been modeled |
| Reviewability | Reader must audit generated SQL | Reader checks the metric name and definition |
| Setup cost | Low; point a server at read-only credentials | Higher; someone must model and maintain metrics |
| Best fit | Exploration, lineage, engineer-reviewed analysis | Recurring business questions and executive reporting |
The table is honest about where raw access wins. Flexibility and setup speed are real advantages, and a semantic layer only covers what someone has modeled. If an engineer asks which tables joined to a given dimension last month, a governed metric layer will not help, and a raw server will. The choice is not either-or for most teams; it depends on the question.
When you can skip the semantic layer
Not every agent workflow needs governed metrics. If the consumer is a data engineer asking about schema changes, row counts, or lineage, the questions are about structure rather than business meaning. "What changed in the orders schema since last deploy?" has a factual answer in the warehouse metadata, and a raw MCP server handles it well.
The same holds when a human reviews every query before anyone relies on the result. An analyst using Claude Code to draft SQL, then reading and running it, is using the agent as a faster typist. The review step catches definitional errors, so governed metrics matter less. The risk rises when the review step disappears, for example when the agent's answer goes straight to a stakeholder or a downstream workflow.
Small teams with one or two core metrics can also get by with a lighter approach: a documented view or a dbt model that already encodes the definition, plus a short instruction file telling the agent to use it. That is a minimal semantic layer without the tooling. It works until the metric count grows or two teams define the same term differently, at which point the informal approach starts to fail.
A practical stack: transport, metrics, and catalog
We think about the agent's context in three layers. MCP is the transport: how the agent reaches systems. The semantic layer is the meaning of the numbers: metrics, dimensions, and grain. The catalog is everything around the data: who owns a table, when it last refreshed, whether it contains PII, and whether it is deprecated. Each layer answers a different question, and skipping one leaves a specific gap.
The catalog layer matters more than it first appears. A metric definition tells the agent what "active customers" means, but not whether the underlying table loaded this morning or failed at 3 a.m. Freshness, ownership, and access policy come from catalog and quality metadata. Our Catalog Agent federates across OpenMetadata, DataHub, Amundsen, Unity Catalog, and Atlan so that this context reaches the agent through the same MCP connection.
On top of those layers, an analysis agent can ground its work. Our Insights Agent does text-to-SQL grounded by the semantic layer and returns analyses with citations and assumptions listed, so a reader can see which definition was used. When the answer depends on a table with a failing quality check, the chained quality context lets the agent say so instead of reporting a number from bad data.
The order of adoption matters too. Most teams get value fastest by starting with raw MCP for engineers, then modeling the five to ten metrics that appear in executive questions, then adding catalog context for ownership and freshness. Doing it in that order avoids a long modeling project before anyone sees an agent working.
How to decide for your team
- •Ask who reads the answer. If the reader is an engineer who checks the SQL, raw access is usually fine; if it is a business stakeholder, require governed metrics.
- •Count the metrics people argue about. If finance and product already define "customer" differently, an agent will inherit that disagreement unless one definition is enforced.
- •Check whether answers are reproducible. Ask the same question five times; if the numbers differ, the agent is guessing at definitions.
- •Start with a short list of governed metrics and route everything else to read-only exploration with human review.
- •Log which metric or table each answer used, so every number can be traced back to a definition.
The reproducibility test is the cheapest one to run. It takes an afternoon, needs no new tooling, and tells you whether your current setup is guessing. If the five answers agree, your table and column documentation may be carrying more weight than expected. If they diverge, you have a concrete case to bring to the team that owns the metrics.
Frequently Asked Questions
Does MCP replace a semantic layer?
No. MCP is a protocol for connecting an agent to tools and data, and the specification says nothing about metric definitions. A semantic layer can be exposed through an MCP server, which is how the two combine, but the protocol does not supply the definitions. Think of MCP as the road and the semantic layer as the map legend: one moves the agent, the other tells it what it is looking at.
Can an agent write correct SQL without a semantic layer?
It can write valid SQL, and for simple structural questions the SQL is often correct. The risk is with business terms. Valid SQL that computes the wrong definition of revenue still runs and still returns plausible numbers. Correctness depends on the question being unambiguous, and business questions often are not, which is the case Cube describes in its context layer argument.
Which semantic layer works with MCP today?
Several do, and the list changes quickly, so check each vendor's current docs. One concrete example is the dbt-mcp server on PyPI, which exposes dbt capabilities, including semantic layer metrics, to MCP clients. If your metrics already live in dbt, that is a low-friction starting point. If they live in another tool, look for that tool's own MCP server.
Is a semantic layer worth it for a small team?
It depends on how many metrics are contested. A team with two stable metrics can encode them in dbt models or views and instruct the agent to use those. The overhead of a full semantic layer pays off when several teams consume the same numbers, when definitions change over time, or when agent answers reach people who will not check the SQL.
What should we do first if we already have a raw MCP server running?
Run the reproducibility test on your five most common business questions, record which answers disagree, and model those metrics first. Keep the raw server for engineers and exploration, and route recurring business questions to governed definitions. This gives you a measured starting point instead of a broad modeling project, and it shows where the guessing actually happens.