Wiring an agent straight to your warehouse over MCP takes about an afternoon.
Explaining to your auditor what it did takes considerably longer.
The design decision hiding inside a config file
MCP makes the connection trivial, which is exactly why what sits behind the server matters more now, not less. There are two ways to build it and they look identical from the outside.
Expose the tables. The agent gets raw schema access and infers meaning. Fast to build, impossible to govern, and every answer is a guess with good grammar.
Expose the semantics. The agent sends intent. The server resolves entities against a typed graph, proves the join path, applies policy for the caller's identity, compiles SQL, and returns a governed result with lineage.
What that changes in practice
| Schema-exposed | Semantics-exposed | |
|---|---|---|
revenue means |
Whatever column matched | One versioned definition |
| Join across 3 tables | Model picks a path | Path proven or request fails |
| Two callers, different rights | Same rows | Different SQL, correct for each |
| Auditor asks "what ran?" | Connection logs | Question → SQL → predicates → result |
The BI-specific part
Business intelligence has a property most agent use cases don't: the output feeds decisions that get defended later. A dashboard number that's wrong gets corrected. A number an agent surfaced into a board pack and nobody can reconstruct is a different category of problem.
So for BI over MCP the requirement isn't "can the agent query" — it's "can we reproduce this answer, with the definitions that were in force, six months from now."
That's not a protocol feature. It's what the layer behind the protocol does.
The full breakdown — the server architecture, tool surface design, and how governed results are shaped — is here:
👉 MCP for Business Intelligence: How AI Agents Should Query Enterprise Data
Originally published at colrows.com/blogs/mcp-business-intelligence
Top comments (0)