Every major data platform now has an MCP server. None of them ship production-ready for enterprise — no user impersonation, no selective tool loading, no gateway integration. We hardened Looker’s and open-sourced the result.
Most “AI + BI” integrations bypass the semantic layer entirely. They give the LLM a list of table schemas and let it write SQL. That approach generates wrong numbers, violates row-level security, and produces metrics that contradict every dashboard in the organization. The entire point of Looker is the semantic model. Bypassing it does not connect AI to your data — it connects AI to your raw tables while pretending they are the same thing.
When enterprise leaders say “connect our AI to our data,” most of them have a vague idea that the data lives in a warehouse and that is where the AI should go. What they do not realize is that the warehouse is exactly where governance, authentication, and authorization challenges converge. And AI makes it worse, not better: an LLM is a probabilistic system, not a deterministic one. Ask an AI chatbot “give me revenue for yesterday” three times and you may get three different SQL queries, three different numbers, and three answers that contradict the dashboard the CFO reviewed that morning. Without a semantic layer enforcing a single authoritative definition of “revenue,” AI on your data is not just inaccurate — it is actively worse than having no AI at all, because now people have conflicting numbers they each believe a machine validated.
This is the third post in a series on production MCP infrastructure. The first post covered context collapse — why connecting 10+ MCP servers dumps 150,000 tokens of tool schemas into your agent’s context window, and how progressive discovery fixes it. The second post covered authentication — the RFC 8693 token exchange pattern that lets per-user identity flow from an upstream gateway to downstream data platforms like Snowflake. This post is about what we found when we took the same production-hardening approach to Looker: existing integrations get the basics right but skip the enterprise requirements that matter most.
If your teams rely on Looker dashboards for trusted numbers, any AI integration must query through that same governed layer — not bypass it with raw SQL. Getting this wrong means your AI gives the CFO different revenue numbers than the dashboard she reviews every Monday, and it means row-level security policies silently stop working.
Google ships a Looker MCP integration, but it does not cover the enterprise requirements that production deployments need: per-user identity, selective tool exposure, and gateway integration. We built an open-source server that handles all three. The rest of this post covers the technical design. Here is what matters for the business case:
Looker’s differentiation has always been LookML — the modeling layer that sits between your database and your analysts. In LookML, a “revenue” dimension is defined once. That definition is what powers every Explore, every dashboard, every API query. When finance runs a revenue report and the AI runs one, they should be computing the same number using the same business logic. LookML makes that guarantee.
Raw SQL access does not. When you give an LLM a list of table schemas and ask it to “calculate revenue,” it will do its best — and it will almost certainly produce a different number from the one in the dashboard. Not because the AI is bad at SQL. Because it does not know which tables to join, which records to exclude, which currency conversions to apply, or which business rules are buried in filters that the data team long ago hardcoded into every query.
Beyond metric consistency, LookML also enforces access control. Row-level security policies in Looker restrict what data individual users can see — regional managers see their region, sales reps see their accounts, and so on. These policies run at the Looker layer. A raw SQL connection runs below it. If your AI agent queries the database directly, every row-level security policy in your Looker instance is silently bypassed.
The right AI + Looker integration queries through LookML, not around it. The LLM describes what it wants in business terms; Looker compiles it to SQL using the governed semantic model. Data governance, metric consistency, and row-level security all apply exactly as they do for human analysts.
Every major data platform now has an MCP integration. Google ships a Looker MCP integration via the MCP Toolbox for Databases. Snowflake has an official server from Snowflake Labs. Tableau has an official server with full OAuth 2.1. BigQuery launched a managed MCP endpoint in early 2026. The ecosystem is maturing fast.
But “has an MCP server” and “production-ready for enterprise multi-tenant deployments” are different things. When we evaluated these servers for the Ultrathink Axon™ platform, we found a consistent pattern: the basics work, but the hard enterprise requirements are missing.
We took the same approach with Looker that we took with Tableau and Malloy Publisher: build a production-hardened server that handles the enterprise requirements the official integrations do not, and open-source it so the ecosystem benefits.
looker-mcp-server is a full-featured Model Context Protocol server for the Looker API. It is available on PyPI, Apache 2.0 licensed, and covers the full Looker API surface with 56 tools across 8 organized groups.
query), execute raw SQL (query_sql), run saved Looks and dashboards. The primary interface
for data retrieval.
Default groups are explore, query,
schema, content, and health
— the tools a data analyst or AI agent needs for production read-and-query
workflows. The modeling,
git, and admin groups are explicitly opt-in,
because they expose write and administrative capabilities that most
deployments should never expose to an agent.
Any MCP server can wrap the Looker API and expose tools. The decisions that separate a production-hardened server from a default integration are about identity, tool surface control, and operational integration. Here is how we approached each.
Every tool you expose to an LLM has a cost: schema tokens, context consumption, and surface area for the model to pick the wrong tool. Fifty-six tools in context for an agent that only needs to run Looker queries is wasteful. Fifty-six tools available to an agent that should never touch admin operations is a security problem.
The --groups flag solves both.
# Minimal: read-only analyst access
looker-mcp-server --groups explore,query
# Standard: analyst + dashboard management
looker-mcp-server --groups explore,query,schema,content,health
# Full access (elevated privilege — use carefully)
looker-mcp-server --groups all
A standard analyst deployment with explore,query
loads 12 tools instead of 56. That is a 90% reduction in context consumption
for the tool schemas, and a complete elimination of write and admin
surface area.
Looker has two distinct deployment models — self-hosted and Google Cloud Core — and they handle user impersonation differently. Getting per-user identity right in both contexts required building three authentication modes into a single server:
login_user API. The user is identified by email from
an upstream request header (typically set by an MCP gateway). Looker’s
row-level security applies as if the user logged in directly. login_user only works for Embed-type users; OAuth is the correct path for
regular users.
The DualModeIdentityProvider routes automatically based
on the deployment type setting and which headers are present in the
request. If neither impersonation header is present, it falls back
to service-account mode. No manual routing logic required in the calling
code.
Why does this matter? Because Looker enforces row-level security at the user level. A regional manager should only see their region’s data. If the MCP server queries Looker as a shared admin account, that restriction disappears. When the server queries as the actual user, the existing access controls apply exactly as intended — without any modifications to Looker’s configuration.
Enterprise authentication is never exactly like any server’s default behavior. You might have a custom token exchange flow, a multi-tenant setup where identity comes from a proprietary header, or an internal SSO system that does not match standard OIDC patterns.
The IdentityProvider protocol is the primary extension
point. Implement
async def resolve(self, context: RequestContext) ->
LookerIdentity and pass your implementation to create_server().
The RequestContext gives you full access to request headers,
the tool name being invoked, the tool group, and the arguments. Every
call to every tool passes through your identity resolution logic.
This is what makes the server composable inside an enterprise platform. Our Axon enterprise wrapper uses a custom identity provider that integrates with our gateway’s OIDC JWT validation — the same token exchange pattern described in our authentication post. The OSS server handles the Looker API; the enterprise layer handles identity. No coupling between them.
Local development and production deployment have fundamentally different transport requirements. stdio is simpler — Claude Code and Claude Desktop can launch the server as a subprocess with no network configuration. But production AI systems need the server running independently, receiving connections over HTTP, and integrating with container orchestration.
One environment variable switches between them:
# stdio (default) — for Claude Code, Claude Desktop
looker-mcp-server --groups explore,query,schema
# streamable-http — for production MCP deployments
LOOKER_TRANSPORT=streamable-http looker-mcp-server --groups all --port 8080
HTTP mode also activates /healthz and
/readyz endpoints. Liveness probes confirm the server
is running; readiness probes verify Looker connectivity with a full
login/logout cycle. These are not optional in production container
deployments — Kubernetes needs them to know when the pod is ready
for traffic and when to restart it.
looker-mcp-server is not a standalone tool. It is one tier in a broader data analyst architecture we are building on the Ultrathink Axon™ platform. The core idea is that not all data questions carry the same risk, so they should not all use the same access pattern. Think of it as different SLA levels for different kinds of analysis.
The architectural principle across all three tiers is the same: data never passes through the agent’s context window. LLMs are not good at data processing. They are good at understanding questions and selecting the right tool. The actual querying, transformation, and visualization happens server-side — compound tools inside the data analyst server query each platform directly, transform results in-process, and return structured output that the chat frontend can render as rich, interactive UI.
When an agent asks for “Q4 revenue by region,” the compound tool queries the semantic layer, builds a Vega-Lite visualization spec server-side, and returns the spec to the frontend — which renders an interactive chart inline in the chat, not a wall of text. The LLM never sees the raw rows. Data analysis requires rich visual output — bar charts, scatter plots, interactive tables — not paragraphs of text summarizing numbers. The tiered data access model feeds into a generative UI layer that renders the right visualization for each response.
For any of these tiers to work securely, the MCP server must execute each query as the requesting user — which is exactly what the identity design above provides. The tiered access model, the user identity design, and the rich visualization layer are not independent choices. They are three parts of the same production-grade data analyst architecture.
The open-source server handles Looker. The enterprise layer handles everything around it. Inside the Axon platform, we apply the same thin-wrapper pattern to every data platform MCP server — Looker, Snowflake, Tableau, Malloy Publisher — so that each one plugs into the tiered data access architecture described above. The Looker wrapper adds:
DualModeIdentityProvider
reads the token from a header — no custom identity provider
needed. Two separate config objects, no env var collisions, and no modifications to the upstream library required. The OSS server handles the Looker API; the wrapper handles identity, tracing, and deployment. This is the same layered approach we use across every data platform server in the Axon stack.
We open-sourced fastmcp-gateway for the same reason: the individual server is not competitive advantage. Our advantage is the Outcome Partnership model — the tiered data access architecture, the visualization layer, and the operational expertise to deploy, monitor, and improve these systems over time. A production-hardened Looker MCP server that anyone can use demonstrates how we think about enterprise AI infrastructure. The full stack around it is where the value compounds.
The MCP ecosystem also needs shared tooling for production-grade problems. Official vendor servers handle the basics well, but the enterprise hardening layer — user impersonation, selective tool loading, gateway integration — is work every production deployment repeats independently. We would rather solve that in the open once than watch the ecosystem duplicate the same effort behind closed doors.
The server is on PyPI:
pip install looker-mcp-server
# or
uv add looker-mcp-serverSet your Looker credentials and run:
export LOOKER_BASE_URL="https://mycompany.looker.com"
export LOOKER_CLIENT_ID="your-api3-client-id"
export LOOKER_CLIENT_SECRET="your-api3-client-secret"
# stdio (local use)
looker-mcp-server --groups explore,query,schema
# HTTP (production)
LOOKER_TRANSPORT=streamable-http looker-mcp-server --groups all --port 8080For Claude Code and Claude Desktop configuration, user impersonation setup, and the full deployment guide, see the README on GitHub.
An LLM writing raw SQL against your warehouse is a probabilistic system making deterministic claims about your business. Ask the same revenue question three times, get three different numbers, and now you have conflicting answers that each look authoritative. The semantic layer exists to prevent exactly this: one definition of “revenue,” one set of access controls, one source of truth — whether the question comes from a human analyst or an AI agent.
Production-grade Looker integration means respecting that governance layer, not bypassing it. It means surfacing existing certified reports before generating new queries. It means querying through the semantic model when new analysis is needed, executing as the actual user so access controls apply, and returning rich interactive visualizations — not paragraphs of text — because data analysis demands more than what an LLM can render in a chat bubble.
These are not advanced features. They are the minimum bar for a system you can put in front of enterprise users.
That is what we built. looker-mcp-server is on GitHub and available on PyPI today. If you need it running in a production enterprise stack — with the tiered data access model, gateway token exchange, and the full Axon observability layer — start the conversation.
Take the next step from insight to action.
No sales pitches. No buzzwords. Just a straightforward discussion about your challenges.