One question I keep getting as a BI MCP builder serving a large enterprise user base: which MCP should I use for this use case?
Not "which one is better." Which doorway for this job.
The question usually arrives in a stronger form: "Why do we need a BI MCP when the warehouse MCP does the job?" The lazy answer is "because BI has a semantic layer." That's true and useless. It doesn't tell a team which doorway to give their agent on Monday.
I got tired of answering it from scratch every time, so I turned the answer into seven toggles. Here they are — and there's an interactive version at the end that gives you the verdict.
The 7 questions
1. Who's asking?
Others — stakeholders, customers, anyone non-technical → BI MCP. They can't validate raw SQL; they need answers built from vetted definitions.
You, and you know the data → warehouse MCP. A data engineer asking for themselves can read the SQL, spot a bad join, re-ask. No curation needed.
2. Does it need a defined business metric?
Yes — "revenue," "churn," "active user" → BI MCP. If two people can define the term differently, the definition must come from the model, not the model's imagination.
No — row counts, null rates, "what's in this table" → warehouse MCP. No business definition at stake; raw SQL is the honest tool.
3. One-off or repeated?
Repeated — dashboards, weekly reports → BI MCP. Repeated questions deserve a curated path: same definition, same shape, every time.
One-off — debugging, "let me check something" → warehouse MCP. Ad-hoc work dies in curation queues.
4. Do the consumers have warehouse access?
No → BI MCP, and this one is decisive. It's the only doorway that works. The BI tool queries under its own service identity while the end user has zero warehouse access; authorization happens at the BI project level. This is not a security hole — it's how BI works. The semantic layer is the authorization boundary.
Yes → either. Through the warehouse MCP the agent acts with the requester's own grants.
5. Exploring or asking a known question?
Exploring a new table, "what's possible here" → warehouse MCP. The curated model can't answer questions it wasn't built for.
Known business question → BI MCP.
6. Does the agent need to write or create?
Yes — DDL, staging tables, "build me a mart" → warehouse MCP. Decisive. The BI doorway is read-only by design.
No → either.
7. Does the semantic model cover this?
No → warehouse MCP, or go model it first. The honest caveat the semantic-layer pitch skips: BI MCP is only as good as the model behind it. An unmodeled question through the BI doorway gets a confident wrong answer or no answer.
The decision rule
Two of these are decisive: no warehouse access → BI MCP; needs writes → warehouse MCP. Otherwise, majority wins. A tie means hybrid — explore in the warehouse MCP, operationalize the metric in the semantic layer, serve it through BI MCP.
"Warehouse MCP" covers BigQuery, Snowflake, Databricks, Fabric. "BI MCP" covers Looker, dbt, Cube — any semantic-layer doorway.
Try it
I built the rubric as an interactive page — seven toggles, live verdict:
https://sangaraju1988.github.io/mcp-doorway-rubric/
And the repo (CC BY 4.0 — use it, credit it):
https://github.com/sangaraju1988/mcp-doorway-rubric
Two caveats
Managed warehouse MCP endpoints ship with guardrails — row caps, runtime caps. They rarely bind for aggregated Q&A, but bulk extraction belongs to the warehouse API, not any MCP doorway.
And unguarded agent + raw warehouse = surprise bills. Cost guardrails (quotas, dry runs, billed-bytes limits) belong in the warehouse MCP setup.
Most mature teams end up running both doorways. The rubric just tells you which one for this job.
Top comments (0)