Is MCP Enough for AI Agents to Query Enterprise Data, or Do You Need a Semantic Layer?

No. The Model Context Protocol specification standardizes how a client discovers and calls tools, and nothing more: it says how an agent invokes a query tool, not what "revenue" or "active customer" means in your company. An agent connected over MCP can run SQL against your warehouse, but without shared metric definitions it will pick a plausible join and a plausible filter, and the answer may be wrong with no error raised.

Key Takeaways

• •MCP is a transport and discovery contract for tools. It defines no business semantics, so metric meaning has to come from somewhere else.
• •An agent that only has a raw SQL tool must guess joins, grain and filters. Wrong answers look identical to right ones.
• •A semantic layer gives the agent governed definitions for metrics and dimensions, so two agents asking the same question get the same number.
• •The strongest setup is MCP for access plus a semantic layer for meaning, with catalog and lineage context beside it.
• •Test any agent setup with a fixed set of questions that have known answers before you let it near a board report.

What MCP actually defines

MCP is a client-server protocol. A server exposes capabilities, and a client such as Claude Code or Cursor discovers and calls them. The MCP specification describes tools as functions a model can invoke, each with a name, a description and a JSON schema for its inputs. The 2025-06-18 revision also covers resources and prompts, so a server offers three kinds of primitive in total. That is a clean, useful contract, and it is why so many data tools now ship an MCP server.

Notice what is absent. The protocol has no concept of a metric, a grain, a fiscal calendar or a join path. A tool called run_query that accepts a SQL string is a perfectly valid MCP tool, and so is one that returns the contents of a table. The protocol validates the shape of the call, not whether the SQL answers the business question the user asked.

This is a deliberate design choice, and we think it is the right one. A transport protocol should not embed one company's definition of churn. But it means that "we have an MCP server" answers the access question and leaves the meaning question completely open. Teams that treat the two as the same problem tend to find out in a review meeting, when two dashboards and one agent disagree.

Where agents fail when MCP is all they have

Give an agent a SQL tool and the schema of a mid-sized warehouse, and it will produce fluent queries. The failure modes are quiet. It joins orders to customers on the wrong key because two columns share a name. It counts refunded orders as revenue because nothing told it otherwise. It sums a snapshot table across dates and double counts. Each query runs, each result is a number, and none of it raises an exception.

The same question also gets different answers on different days. Ask "what was revenue last quarter" twice and the model may choose a different source table each time, because several tables plausibly qualify. For a human analyst that ambiguity is resolved by tribal knowledge. For an agent, the only tribal knowledge available is what is in the prompt or the tool responses.

Questions our users actually run make this concrete: "Why did row counts drop 40% overnight?" or "Show freshness scores for all gold tables." Both need to know which tables are authoritative and how freshness is defined here. A protocol cannot supply that. A governed definition layer and a catalog can, and the agent has to be pointed at them rather than left to infer.

What a semantic layer adds

A semantic layer is a governed set of definitions: metrics, dimensions, entities and the relationships between them, written once and compiled to SQL on demand. The dbt documentation on metrics lists five metric types in MetricFlow: simple, ratio, cumulative, derived and conversion. Each one encodes a calculation pattern so that the agent requests a metric by name instead of reconstructing the math from raw columns.

The important property is that the agent stops writing the risky part. Instead of composing joins and aggregations, it asks for a metric grouped by a dimension and a time grain, and the layer generates the SQL. Fewer degrees of freedom means fewer ways to be silently wrong. It also means a metric change is made in one reviewed place and every consumer, human or agent, picks it up.

Warehouse vendors have reached the same conclusion for their own assistants. The Snowflake documentation for Cortex Analyst describes a semantic model specification that the assistant relies on to translate questions into SQL. Different products, same pattern: natural-language questions work reliably when a definition layer sits between the question and the tables.

A five-layer way to think about the stack

We find it easier to reason about this as layers than as a binary choice between MCP and a semantic layer. Each layer answers a different question for the agent, and a gap in any one of them shows up as a different kind of wrong answer.

• •Layer 1, access: MCP servers expose the warehouse, catalog and orchestrator as callable tools.
• •Layer 2, meaning: a semantic layer defines metrics, dimensions and grain.
• •Layer 3, discovery: a catalog says which tables are authoritative, who owns them and how fresh they are.
• •Layer 4, lineage and blast radius: the agent can see what depends on what before it recommends a change.
• •Layer 5, control: approvals, audit trails and read-only defaults decide what the agent may do.

MCP lives in layer 1 and also becomes the way layers 2 through 5 are delivered to the agent, since each can be exposed as another MCP server. That is the useful reading of the protocol: it is the plumbing that lets meaning, discovery and control reach the agent, not a substitute for them.

Most teams start at layer 1 because it is the quickest to demo. The order that pays off is the reverse for correctness: define the five or ten metrics that executives actually ask about, mark the authoritative tables, and only then widen the agent's access.

How to test whether your setup is enough

Do not decide this by argument. Write down twenty questions whose answers you already know, drawn from reports finance or product has signed off. Include some that need a join, some that need a time window, and a few that are deliberately ambiguous, such as "how many active customers do we have?" Run each one several times through the agent, and record the answer, the SQL or metric call, and whether it matched.

Two numbers matter: accuracy against the known answer, and consistency across repeated runs. An agent with only raw SQL access will often score acceptably on accuracy for simple questions and badly on consistency for ambiguous ones. If consistency is poor, the fix is rarely a better prompt. It is usually a missing definition.

Rerun the suite whenever the schema changes. A renamed column or a new source table can quietly shift answers. Treating the question set as a regression test, kept in version control beside the metric definitions, turns "is the agent trustworthy" into something you can check on every change.

How Data Workers fits in

We build for the case where MCP is the delivery mechanism and meaning comes from governed context. The Insights Agent produces text-to-SQL analyses grounded by the semantic layer, and it states its assumptions and cites the definitions it used, so a reviewer can see why a number came out as it did. It does not invent a join path when a metric definition exists.

The Catalog Agent supplies the discovery layer by federating across the catalogs a team already runs, so the question of which table is authoritative has an answer the Insights Agent can read. Because every agent is an MCP server, an engineer can ask from Claude Code or Cursor: "What's the blast radius if I drop this column?" and get an answer that combines lineage and definitions.

The OSS edition is Apache 2.0, runs locally and is read-only by default. That default matters for this topic: an agent that can only read cannot corrupt data while you are still tuning its definitions. Writes, approvals and audit trails come with the Pro edition once you trust the answers.

Frequently Asked Questions

Can an agent query my warehouse over MCP without a semantic layer?

Yes, technically. Any MCP server that exposes a query tool lets an agent run SQL. What you give up is consistency and correctness guarantees on business metrics. For exploratory questions on a table the user names explicitly, raw access can be fine. For recurring numbers that people act on, put definitions in front of the agent.

Is a semantic layer a replacement for MCP?

No. They solve different problems. A semantic layer defines what metrics mean, and MCP is how an agent reaches tools. Most semantic layers can be exposed as MCP servers, so the practical architecture uses both, with the protocol carrying the governed definitions to the agent.

Where should a team start if it has no semantic layer today?

Start small. Pick the handful of metrics that appear in executive reporting, define them in code with owners, and mark their source tables in your catalog. Point the agent at those first and keep it read-only. Add metrics as the question log shows demand, and grow the regression question set at the same pace.

The reference implementation and issue tracker for the protocol are public in the MCP repository on GitHub, which is a good place to follow how the specification evolves and to see what is deliberately left out of scope.