MCP for Data Analytics: What the Model Context Protocol Actually Changes (and What It Does Not)
Last updated: May 2026
A backend engineer joins a data team’s standup with a question that is starting to come up everywhere. The company just rolled out Claude and ChatGPT to the whole organization, and every department wants to “point it at our data.” Security has been saying no for months. The data platform lead has been saying maybe. The CEO has now sent a Slack message that includes the word “unblock.”
Eighteen months ago, this conversation would have ended in a custom integration project, a quarter of engineering time, and a brittle integration that broke every time a model provider released a new version. In 2026, it ends with one phrase: MCP. The Model Context Protocol has gone from an interesting Anthropic experiment in late 2024 to the de facto integration layer between AI assistants and data systems. Every major warehouse vendor has shipped a server. Every major AI client knows how to talk to one. The question for data teams is no longer whether to support MCP, but how to support it without creating a governance and security problem the team will spend the next two years cleaning up.
This guide walks through what MCP actually is, why it matters specifically for data teams (as opposed to AI engineers more broadly), what the production landscape looks like now that the vendors have moved, and the patterns that are working in real deployments.
What MCP is, in one paragraph that does not lie to you
The Model Context Protocol is an open JSON-RPC standard that defines a single way for AI applications to discover and call tools, read resources, and use prompts exposed by external systems. Instead of writing one integration for Claude, a different one for ChatGPT, and a third for whichever model your CIO greenlit last quarter, you build one MCP server. Any compliant AI client can use it. The official MCP documentation maintained by the Agentic AI Foundation describes the architecture in detail, and at this point most of the production tooling has converged on it as a baseline.
The growth numbers reflect how quickly the ecosystem has shifted. MCP grew from roughly 2 million monthly SDK downloads at launch in November 2024 to 97 million by March 2026, a level of adoption that took React roughly three years to reach. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation, with Block and OpenAI as co-founders, which removed the last serious concern about single-vendor capture and made adoption a much easier political call inside enterprises.
What MCP is not is also worth saying clearly. It is not a query engine. It is not a semantic layer. It is not a data catalog. It does not replace your warehouse, your transformation tool, or your governance platform. It is an integration layer that sits between AI applications and the systems they need to read from or act on.
Why this matters specifically to data teams
For most software engineering teams, MCP is a quality-of-life improvement. For data teams, it is closer to an architectural pivot.
The reason is that data teams are the team that gets the request. When the CEO asks why the AI assistant cannot answer a question about last quarter’s revenue, the request lands with the platform team that owns the warehouse, not the team that bought the AI license. When a business user asks why the answer Claude gave is different from the dashboard, the data team is the one expected to reconcile it. The mechanics of how AI assistants talk to data systems are the data team’s problem regardless of who originally introduced the assistant.
The pre-MCP version of solving this problem was uniformly bad. Either someone exported a CSV and pasted it into a chat, which produced answers that were stale and ungoverned, or a developer hand-wrote a custom integration against a specific model’s function calling interface, which broke every time the model changed and never extended to a second model. The result was that most attempts to connect AI assistants to enterprise data stalled at the proof-of-concept stage.
MCP changes the economics. The integration is written once against an open standard. New AI clients work without new integration code. The data team can focus on what the AI assistant can do (which datasets it can read, with which permissions, exposing which tools) rather than on how each specific assistant talks to the warehouse. The same architectural argument that makes QuantumLayers’ QL-Agent reliable as a conversational layer over a governed analytics platform applies to the MCP server pattern more broadly. The AI does not need to reinvent data access from scratch on every request. It calls structured, validated tools that the data team has explicitly designed and authorized.
What the warehouse vendors actually shipped
Every major warehouse has now shipped or partnered on MCP support, and the shape of those offerings tells you a lot about where the category is heading. ChatForest’s detailed review of the warehouse and lakehouse MCP server landscape is one of the more useful technical comparisons published in early 2026.
Snowflake ships a managed MCP server as a first-class object inside Snowflake itself. You define it with CREATE MCP SERVER and configure tools that map to Cortex Analyst (natural language to SQL), Cortex Search (semantic search over unstructured data), Python UDFs, and a SQL execution tool. The Snowflake-managed MCP server documentation is the most thorough vendor reference for setting one up. The key architectural point is that the MCP server reuses Snowflake’s existing identity, role-based access control, and masking policies, so an agent calling the server inherits the same governance that applies to human users.
Databricks ships Managed MCP Servers exposed through Unity Catalog, including the Genie Space MCP Server for natural language to SQL, a Vector Search server, and UC Function servers for calling registered functions as tools. The integration with Unity Catalog is the differentiator. Permissions, lineage, and audit logging are inherited automatically rather than reimplemented in a separate layer.
BigQuery offers a managed remote MCP server and exposes its Conversational Analytics API as MCP tools, including ask_data_insights for natural language analysis and bigquery_forecast for time-series prediction. The Google Cloud blog post on AI-based forecasting via MCP and ADK walks through the end-to-end pattern.
ClickHouse, DuckDB, and Redshift all have official or vendor-blessed MCP servers, with ClickHouse’s being the most-starred open-source warehouse MCP server in the community.
The common thread is significant. Read-only is the default across nearly every vendor server. Write operations require explicit opt-in. Authentication ties back to the existing identity provider rather than introducing a new credential model. None of these things were guaranteed when the protocol was first released, and the convergence on safe defaults is one of the better outcomes of the standardization push.
The pattern that connects MCP to the semantic layer
For data teams that have already invested in a semantic layer (and the pressure to do so has accelerated significantly in 2026), the relationship between MCP and the semantic layer is one of the most important architectural decisions on the table.
The pattern that works puts the semantic layer in front of the warehouse and exposes MCP tools that call through it. The AI client asks a question. The MCP server resolves the question against semantic definitions of metrics and dimensions, generates SQL that uses governed business logic rather than free-form column references, and executes against the warehouse. The result is consistent regardless of which AI client asked the question, because every assistant is hitting the same definition of “revenue” or “active customer.”
Google’s recent post on connecting Looker to Gemini Enterprise through the MCP Toolbox illustrates this directly. Looker’s LookML semantic models are exposed as MCP tools that the agent uses to answer questions, rather than the agent writing SQL against raw tables. The same architecture is increasingly visible across vendors: Snowflake’s Cortex Analyst is essentially a managed semantic layer reachable through MCP, and Databricks’ Genie functions the same way.
The alternative pattern, where the AI client writes SQL directly against the warehouse through a SYSTEM_EXECUTE_SQL style tool, works in narrow technical demos and tends to produce inconsistent or wrong answers at any scale. The same metric gets defined three different ways depending on which model handled the request. The data team ends up debugging answers rather than improving infrastructure. This is the same hallucination problem the semantic layer was invented to solve, and MCP without semantic governance just exposes it through a new channel.
The protocol is the integration layer. The reliability of the answers depends entirely on what the tools behind the protocol actually compute. A team that wires an AI client to raw SQL execution and a team that wires the same client through a governed semantic layer are running the same protocol and getting wildly different production outcomes.
The security conversation that has to happen
The hardest part of rolling out MCP in an enterprise is not technical. It is the conversation between the data team and the security team, and the failure mode is well-documented.
The shortest path between an AI client and a warehouse is an over-permissioned shared credential. Someone provisions a service account so Claude can connect. Someone drops a personal access token into the MCP client config. Someone tells thirty analysts to share the same warehouse credential because building per-user controls felt like a six-week project nobody budgeted. The Strata post on Databricks and Snowflake MCP servers that security teams will actually approve lays out the alternative in detail.
The pattern that survives review uses delegated authority. Tokens carry an act claim that identifies which AI client is acting, a sub claim that resolves to the human principal already governed in your identity provider, and a short expiration window. When something goes wrong at three in the morning, you can disable the one AI client without locking out the analyst whose credentials it was acting under. Without this distinction, the audit trail is unusable and the security team will not sign off.
For data teams, the practical implication is that the MCP rollout cannot be planned independently of the identity and access architecture. The decisions about federation, token exchange, and audit logging happen before the first server gets connected, not after. Teams that try to bolt these things on after deployment generally end up redoing the deployment.
What changes for observability when AI is making the queries
Once AI assistants are issuing meaningful query volume against the warehouse, the observability tooling that data teams have built over the last two years starts to face questions it was not designed to answer.
Schema change alerts that fire when a column is renamed assume that a human pushed the change. They do not naturally distinguish between human-initiated changes and AI-initiated tool calls, and the cost profile of the two is very different. A failed dashboard query is contained. A failed tool call inside an agent’s reasoning loop can cascade into a long, expensive sequence of follow-up calls as the agent tries to recover.
The patterns emerging in production look like layered telemetry. The MCP server logs every tool invocation with the requesting principal, the tool, the parameters, and the response. The warehouse logs the resulting query and its cost. The agent framework logs the reasoning trace. Joining these together is non-trivial, and the tooling is still catching up, but the teams that are doing it well are already producing dashboards that look very different from traditional query monitoring: cost by AI client, success rate by tool, distribution of question types, drift between tool definitions and the questions agents are actually trying to answer.
If your observability stack today centers on dbt test results and freshness checks, MCP traffic is going to expose gaps in coverage. The expansion is real work, not a config change.
What to do if you are starting from zero
For data teams that have not yet stood up MCP, the realistic starting point is narrower than the marketing suggests.
Pick one warehouse, one AI client, and one read-only use case. Most teams start with Snowflake plus Claude plus a question like “let analysts ask Slack-style questions about our customer table.” The constraints matter. One warehouse means you only have one server to configure. One AI client means you only have to negotiate identity federation once. Read-only means the security review is shorter. Single-use-case means you can measure whether it worked.
Build the semantic layer integration on day one. Skipping this and exposing raw SQL execution looks faster in the short run and creates problems that scale with adoption. If you have a dbt Semantic Layer, Cortex Analyst, Genie, or LookML model already in place, route the MCP tools through it. If you do not, this is the moment to start, because every MCP tool you ship without semantic grounding becomes a future migration.
Plan the identity story before the first deployment. Talk to security about how delegated authority is going to work, which AI clients will be authorized, how tokens will be issued and expired, and how audit logs will flow into the existing SIEM. The teams that defer this conversation generally end up with shadow deployments that do not pass review six months later.
Instrument every tool call from day one. The cost of adding observability later, when MCP traffic is already mixed with normal warehouse traffic, is much higher than adding it upfront.
Treat the first deployment as a pilot, not a platform. The integration layer is mature. The organizational patterns around it are not. Plan for at least one rebuild of the deployment as you learn what the early users actually want versus what you assumed they wanted.
The bottom line
MCP is no longer a speculative bet. Every major warehouse vendor ships a server. Every major AI client knows how to use one. The protocol is governed by a foundation rather than a vendor. Adoption has moved faster than any other infrastructure protocol in recent memory, and the case for building bespoke integrations between AI assistants and data systems is now hard to defend.
What is still genuinely difficult is everything around the protocol. The semantic layer that makes the answers reliable. The identity architecture that makes the security team comfortable. The observability that lets the data team understand what the agents are actually doing. The governance work that defines which tools agents can call, with which permissions, against which datasets.
The teams getting value from MCP today are not the ones with the most servers deployed. They are the ones that treated the rollout as a data platform initiative with security, governance, and observability planned alongside the integration. The protocol is the easy part. The discipline around it is where the real work lives.
Lurika is an independent publication covering data analytics for non-technical teams. We are not owned by any analytics vendor.
