Your Semantic Layer Needs an MCP Server

A safe front door for AI agents to your data

Read free for non members

I wrote recently about semantic layers, the idea that a metric like revenue should be defined once, as code, so every tool that asks for it gets the same answer. That solves a real problem. But it quietly assumes the thing asking for revenue is a dashboard, or a person writing SQL who knows the semantic layer exists.

That assumption is already breaking. More teams are pointing AI agents at their data, and an agent does not automatically know your semantic layer exists either. Left alone, it does what any capable model does when asked a question about your data. It looks at the tables it can reach, writes its own SQL, and guesses. Sometimes the guess is close. Sometimes it silently excludes refunds, or double counts a join, and hands back a confident, wrong number. This is the exact problem the semantic layer was built to prevent, just moved one layer up.

The access problem nobody solved yet

A semantic layer fixes where a definition lives. It does not fix how something outside your organization’s usual tools, like an agent, actually reaches that definition.

For a human, this is not really a problem. You open the BI tool, click on the metric, done. An agent does not click anything. It needs some kind of interface it can call, with a clear description of what each call does, so it can decide which one to use for a given question. Historically that interface has been custom for every product. A dashboard vendor builds its own connector to your warehouse, a notebook tool builds another, and an agent framework builds yet another, each with its own quirks and its own way of authenticating.

The Model Context Protocol, or MCP, is Anthropic’s attempt to standardize that interface. Instead of every AI application inventing its own way to connect to your data, MCP defines a common protocol :

a server exposes a set of tools, described in a way any compliant agent can understand, and any MCP client can call them the same way.

It is less a new product and more an agreed shape for the connection.

In simple terms, an MCP server works like an API built for a model instead of a developer. It hands the model a small menu of named functions, each with a plain description and the parameters it expects. The model’s only job is to pick the right one and fill in the parameters. It never writes the underlying code, it just decides what to call, and the server runs the real logic behind it.

What this looks like for a semantic layer

Here is where the two ideas meet. dbt now ships an MCP server that sits directly on top of the dbt Semantic Layer. Instead of giving an agent raw warehouse credentials and hoping it writes correct SQL, the dbt MCP server exposes a small set of purpose built tools :

list_metrics -> returns every metric defined in the project
get_dimensions -> returns the dimensions available for a metric
get_entities -> returns the join keys available for a metric
query_metrics -> executes a query against a metric definition
get_metrics_compiled_sql -> returns the SQL MetricFlow generated for a metric

An agent asked “what was revenue last month, broken down by region” does not write a query against fct_orders. It calls list_metrics, finds revenue, calls get_dimensions to confirm region is available, then calls query_metrics. The SQL that eventually runs is the exact same SQL the semantic layer would generate for a dashboard. The agent never gets the chance to reinvent the definition, because it never gets raw SQL access in the first place.

A diagram of MCP server in action

Warehouse vendors are converging on the same pattern from the other direction. Snowflake now ships a managed MCP server that exposes Cortex Analyst as a tool, so an agent can ask a question in natural language and get SQL generated against a governed semantic view, all behind Snowflake’s own role based access control. The details differ from dbt’s approach, but the shape is identical : do not hand an agent a warehouse connection, hand it a small, described, permissioned set of tools.

Why this matters for any company with a semantic layer

If you already invested in defining your metrics once, an MCP server is close to a free extension of that investment. You are not building new logic. You are exposing the logic you already have, through an interface agents can actually use safely.

The safety part matters as much as the correctness part. A raw database connection cannot easily express you may query metrics, but you may not run an unbounded select on the raw orders table or you may only see data for the region you are scoped to. A tool based interface can. Each tool is a narrow, named action, so the same governance instincts that shaped the semantic layer, one definition, one place, one set of permissions, extend naturally to what an agent is allowed to do. BigQuery’s MCP server, for example, lets you cap the bytes a query is allowed to scan, something you would never bother enforcing in a normal BI connection but suddenly want the moment an agent is the one writing queries.

None of this requires a large team or a new platform. If you already run dbt, the MCP server is close to a configuration exercise, not a build. The bigger shift is mental : treating the semantic layer not just as a source of truth for dashboards, but as the one thing every consumer, human or agent, should be forced to go through.

A semantic layer defines what a metric means, but an agent still needs a safe, described way to actually reach that definition, and that is exactly the gap MCP was built to close.

Conclusion

The semantic layer answered what does revenue mean. MCP answers how does anything outside a human in a BI tool get to ask. Neither one is complete without the other. If your organization has already centralized its metric definitions, connecting an MCP server on top of them is one of the more useful, low effort things you can do this year, before someone quietly points an agent straight at the warehouse and finds out the hard way why that definition existed in the first place.

Thanks for reading, I hope you enjoyed this article, you can find more of my writing on my page !

[embed]Introducing the Model Context Protocol The Model Context Protocol (MCP) is an open standard for connecting AI assistants to the systems where data lives…www.anthropic.com

[embed]Introducing the dbt MCP Server - Bringing Structured Data to AI Workflows and Agents | dbt… We're open‑sourcing an experimental dbt MCP server so LLMs and agents can discover, query, and run your dbt project.docs.getdbt.com

[embed]Snowflake-managed MCP server | Snowflake Documentation Note Snowflake supports Model Context Protocol revision 2025-11-25. Model Context Protocol (MCP), is an open-source…docs.snowflake.com