3 agent frameworks. 4 data sources. 12 brittle connectors.
Then someone renames a column and three agents break at once. MCP fixes the wiring — but the wiring was the easy part.
What an MCP semantic layer server actually exposes
The design decision is what your tool surface represents. Expose tables and every agent infers meaning independently. Expose semantics and they all compile through the same graph.
A governed server exposes something closer to:
| Tool | Returns |
|---|---|
list_concepts |
Typed entities and metrics the caller may see |
describe_concept |
Definition, grain, filters, allowed dimensions |
resolve_intent |
A typed plan — or a refusal with the reason |
execute |
Governed result + the SQL + predicates applied |
Notice there's no run_sql. That's deliberate — the moment you expose arbitrary SQL execution, every governance guarantee becomes advisory.
The request path
Intent → context resolution → constrained planning → governed execution.
- Agent sends intent plus caller identity
- Server resolves concepts against the versioned semantic graph
- Planner proves a join path — no path, compilation fails
- RBAC and ABAC predicates injected for that identity
- Dialect-perfect SQL emitted and executed
- Result returned with lineage and an audit record
The no-rip-and-replace part
This sits above your warehouse, not instead of it. Snowflake, Databricks, BigQuery and Postgres stay where they are; the layer reads your existing catalogs and BI models to build the graph, then compiles down to each engine's dialect.
The most common objection is migration fatigue — teams have spent millions consolidating and won't move again. They don't have to. Additive layers are the only ones that get deployed.
And because MCP and REST can front the same compiled core, switching protocols later never means re-proving your governance.
The full breakdown — the full architecture, code for the server, the tool schemas, and the integration path — is here:
👉 How to Build an MCP Semantic Layer Server (Architecture, Code, and the No-Rip-and-Replace Case)
Originally published at colrows.com/blogs/mcp-semantic-layer-integration
Top comments (2)
Strong choice to expose semantic concepts rather than tables. I would make semantic versioning part of the execution contract, too:
resolve_intentshould return a plan bound to the semantic-graph version, metric/definition hashes, policy version, and relevant engine capabilities.executeshould reject the plan if any binding changed instead of silently recompiling it against a new definition.That matters when an upstream BI model changes between planning and execution. A safe rollout can dual-run candidate graph versions, compare grain/join paths/results, then promote explicitly. And the lineage record should preserve the resolved grain, join path, filters, and injected policy predicates—not only the generated SQL. That turns the semantic layer from a naming abstraction into an auditable compatibility boundary.
Spot on, Mads. Binding the compiled plan to a cryptographic hash of the graph version, policy state, and target dialect capabilities makes execution strictly deterministic rather than probabilistic.
If an upstream model updates between 'resolve_intent' and 'execute', failing fast due to a version mismatch prevents silent data drift and non-reproducible agent runs. Furthermore, capturing the entire resolution context - resolved grain, join paths, and injected policy predicates - directly inside the audit record elevates lineage from a plain SQL dump to a fully verifiable execution proof.
The dual-run candidate graph pattern for canary testing graph updates is also a fantastic approach for safe enterprise rollouts. Appreciate the sharp feedback!