Snowflake, Databricks and BigQuery MCP servers: governed access

An MCP server for Snowflake, Databricks or BigQuery gives AI agents a standard, authenticated way to discover and call warehouse tools, and all three vendors now run one as a managed service. Governed access depends less on the server than on three decisions around it: which identity the agent runs as, whether it gets a semantic tool or raw SQL, and which tools it can see at all. For business questions, route agents to a semantic tool under the user’s own identity, and keep raw SQL for engineers, read-only, on a separate server.

Everything below reflects vendor documentation as of November 2026. Several of these features moved from preview to GA, or were renamed, within the last year, so check the linked pages before you commit to a design.

What does an MCP server for a data warehouse actually do?

The Model Context Protocol defines how an AI application (the host, such as Claude, ChatGPT, Cursor or your own agent) connects through a client to servers that expose tools, resources and prompts. For a warehouse, the tools matter most. A client calls tools/list to see what is available, then tools/call with arguments the model produced.

Warehouse MCP tools fall into three kinds, and governance differs for each:

Tool kind	Examples	What the model controls	Main risk
Semantic or agent tool	Cortex Agent over semantic views, Genie One, Looker semantic models	The question, sometimes metric and filter choices	Picking the wrong metric or time window
Raw SQL tool	SYSTEM_EXECUTE_SQL, system.ai.dbsql, execute_sql_readonly	The whole query	Wrong joins, broad reads, writes, cost
Metadata tool	List datasets, get table info, catalog search, lineage	What to look up	Leaking schema or tags; write tools in catalogs

Two protocol details matter for security reviews. First, the authorization spec builds on OAuth 2.1 and requires clients to use resource indicators (RFC 8707), so a token is bound to one MCP server, and servers must reject tokens issued for anyone else. The MCP security best practices explicitly forbid token passthrough. Second, the protocol is still moving. The 2026-07-28 revision made MCP stateless and removed the initialize handshake and session IDs. Google’s remote servers support 2026-07-28, while Snowflake documents support for 2025-11-25. Your MCP client has to handle both, which is worth testing before a pilot rather than during one.

How does the Snowflake MCP server work?

The Snowflake-managed MCP server went GA on November 4, 2025. It is a schema-level object, created with CREATE MCP SERVER ... FROM SPECIFICATION, and served at https://<account_url>/api/v2/databases/{db}/schemas/{schema}/mcp-servers/{name}. The earlier community project, Snowflake-Labs/mcp, is marked deprecated and points to the managed server, so do not start anything new on it.

The specification lists tools by type: CORTEX_AGENT_RUN, CORTEX_ANALYST_MESSAGE (semantic views only, not the older semantic model files), CORTEX_SEARCH_SERVICE_QUERY, SYSTEM_EXECUTE_SQL, GENERIC for UDFs and stored procedures, and CODING_AGENT.

Snowflake’s own guidance is the most useful line in the docs. For governed business questions, expose a Cortex Agent as the only client-facing tool on that server. Putting SYSTEM_EXECUTE_SQL on the same server lets the client bypass the agent’s semantic views and verified queries, so if you need direct SQL, put it on a separate server with its own least-privileged role. In practice that looks like this:

-- Server for business users: one governed tool
CREATE OR REPLACE MCP SERVER analytics.agents.finance_mcp
  FROM SPECIFICATION $$
  tools:
    - title: "Finance metrics agent"
      name: "finance_agent"
      type: "CORTEX_AGENT_RUN"
      identifier: "analytics.agents.finance_agent"
      description: "Answers questions on revenue, margin and invoices from governed semantic views."
  $$;

-- Separate server for engineers: read-only SQL on its own warehouse
CREATE OR REPLACE MCP SERVER analytics.agents.eng_sql_mcp
  FROM SPECIFICATION $$
  tools:
    - title: "Read-only SQL"
      name: "sql_readonly"
      type: "SYSTEM_EXECUTE_SQL"
      description: "Runs SELECT queries against development databases."
      config:
        read_only: true
        query_timeout: 120
        warehouse: "AGENT_XS_WH"
  $$;

GRANT USAGE ON MCP SERVER analytics.agents.finance_mcp TO ROLE finance_agent_users;

The names are illustrative. The access model has three points worth knowing:

• USAGE on the server lets a role connect and discover tools, but each tool needs its own grant: SELECT on the semantic view, USAGE on the agent, search service or function.
• Authentication defaults to Snowflake OAuth, with optional External OAuth so clients sign in through Okta or Microsoft Entra ID. Dynamic client registration is not supported. OAuth sessions use the user’s DEFAULT_ROLE as primary role unless you advertise other role scopes, and the recommended configuration leaves secondary roles off (OAUTH_USE_SECONDARY_ROLES = NONE).
• Tool annotations such as readOnlyHint are client hints. Snowflake states they are not security controls; the role is.

Then the documented limits: 50 tools per server, tool responses truncated at 250 KB for SQL and generic tools, a maximum recursion depth of 10 when agents call MCP servers that call agents, and MCP server objects are not replicated in failover groups, so your DR runbook has to recreate them.

What does Databricks offer for MCP?

Databricks now provides MCPs in the system.ai schema, each a Unity Catalog securable invoked through Unity Gateway at https://<workspace-hostname>/ai-gateway/mcp-services/<mcp-name>. Two are relevant here:

• Genie One MCP (system.ai.genie_one_mcp) is generally available and is what Databricks recommends for natural-language business questions. It grounds answers in Genie Ontology, which Databricks calls your governed semantic layer, and enforces Unity Catalog permissions on every request. Answers are asynchronous: the agent calls genie_ask, then polls.
• Databricks SQL MCP (system.ai.dbsql) runs the SQL it is given with the caller’s Unity Catalog and warehouse permissions. It needs the Unity Gateway beta. It permits reads and writes by default; set disallow_writes to true in the built-in system.ai.dbsql_policy to make it read-only. Databricks is candid that it carries no semantic context.

Governance sits in Unity Gateway, which is still marked Beta for MCP services. You can restrict which tools a service exposes, attach service policies that allow, deny or require human approval for a call before it runs and on its result, set rate limits, and read invocations (mcpCall) from system.access.audit. On identity, Databricks recommends on-behalf-of-user OAuth for interactive use and a service principal with OAuth M2M for unattended agents. Like Snowflake, it does not support dynamic client registration, so an account admin registers each client.

Two operational traps. The older workspace endpoints under /api/2.0/mcp/ bypass Unity Gateway entirely: no MCP-level grants, policies or tracing. And the beta Genie endpoint /api/2.0/mcp/genie was scheduled for sunset on October 31, 2026, so any integration still pointing at it needs checking now. If you use workspace IP access lists, remember that hosted clients such as a Claude connector or ChatGPT call from the provider’s IP ranges, not from your VPN.

How do you connect AI agents to BigQuery with MCP?

The BigQuery remote MCP server lives at https://bigquery.googleapis.com/mcp and is enabled with the BigQuery API. The caller needs roles/mcp.toolUser plus BigQuery Job User and Data Viewer, or equivalent permissions. Its tools cover listing datasets and tables, table metadata, execute_sql_readonly, execute_sql and job polling. Only execute_sql can write, and Google suggests denying it with an IAM deny policy on the tool.isReadOnly attribute. Deny policies can also match the tool name and the OAuth client ID, so you can block a specific AI application.

Useful details for operations: queries from the read-only tool carry the job label goog-mcp-server: true, which makes agent spend easy to isolate in billing exports; queries are cut off after three minutes by default; results are capped at 3,000 rows. Google recommends a separate identity for agents. Model Armor can screen MCP requests and responses for prompt injection and sensitive data, but with logging enabled it logs the full payload, and in regions where Model Armor isn’t available routing behaviour can break data residency. Read both caveats before you switch it on.

For local and custom tools, MCP Toolbox for Databases ships a prebuilt BigQuery configuration and is the route Google suggests when you want a tool over a parameterized query. Google announced Toolbox 1.0 as GA in June 2026.

The BigQuery server itself is a SQL and metadata server with no semantic layer. For governed business questions, Google points to the Conversational Analytics API, GA for BigQuery and Looker since June 23, 2026, and to a managed MCP server for Looker semantic models that was announced in preview in June.

Snowflake vs Databricks vs BigQuery MCP: how do they compare?

	Snowflake	Databricks	BigQuery
Managed endpoint	CREATE MCP SERVER object per schema	system.ai.* MCPs via Unity Gateway	bigquery.googleapis.com/mcp
Governed tool for business questions	Cortex Agent or Cortex Analyst over semantic views	Genie One MCP (GA)	Conversational Analytics API; Looker MCP (preview)
Raw SQL tool, default	SYSTEM_EXECUTE_SQL, read_only: true	system.ai.dbsql, reads and writes	execute_sql_readonly plus read-write execute_sql
How to block writes	Option plus role grants	disallow_writes policy	IAM deny on tool.isReadOnly
Identity	Snowflake OAuth or External OAuth; role scopes	On-behalf-of-user OAuth or service principal	Any Google Cloud identity, OAuth 2.0 with IAM
Per-call policy	Grants per tool	Service policies, approval, rate limits (Beta)	IAM allow/deny on tool, service, client ID; Model Armor
Audit	Not specified on the MCP server page	system.access.audit, system.ai_gateway.usage	Job label goog-mcp-server: true, Cloud audit logs
Documented limits	50 tools, 250 KB responses	Truncated results, async polling	3 min queries, 3,000 rows

How do you keep agent access to the warehouse governed?

The platform pieces differ, but the design we recommend is the same on all three: separate lanes by purpose, and make the warehouse’s existing security do the work.

 business user / agent             engineer / coding agent          any agent
         |                                  |                            |
         v                                  v                            v
  semantic / agent tool              read-only SQL tool          catalog metadata tool
  (Cortex Agent, Genie One,          (separate server, own        (DataHub, dbt MCP:
   Looker, dbt SL, Lightdash)         role, dev data, small WH)    owners, PII tags, lineage)
         |  runs as the user                |  runs as a narrow role      |  read-only tools
         v                                  v                            v
  +---------------------------------------------------------------------------+
  | warehouse: grants, row policies, masking, audit, cost attribution         |
  +---------------------------------------------------------------------------+

Identity first

Interactive agents should act as the person asking, through OAuth, so that row-level rules, masking and audit logs behave exactly as they do for that person’s dashboards. Unattended agents get their own service identity with a role scoped to one domain. The pattern to avoid is a single personal access token with a broad role pasted into a desktop client. Snowflake’s docs warn against hardcoded tokens and ask for the least-privileged role when a token is unavoidable.

Expose the fewest tools that do the job

Every tool description goes into the model’s context, and every extra tool is another way to be wrong. Google offers toolsets for this reason; Databricks lets you select tools per MCP service; Snowflake caps a server at 50 tools and notes that higher counts degrade tool selection. Review third-party server descriptions too: Snowflake explicitly names tool poisoning and tool shadowing as risks when you combine servers.

Decide where result rows may go

An MCP call returns data to the model provider your host uses. Prompts are only half of the data protection question; query results are the other half. Decide per domain whether rows may leave your tenancy, and mask or exclude personal data in the semantic layer or with warehouse policies rather than in prompt instructions.

Put a budget on it

Agents retry, poll and explore. Give agent traffic its own small warehouse or compute (Snowflake’s warehouse option per tool, Databricks’ warehouse_id in _meta, a dedicated billing project on BigQuery), set timeouts, and use the labels and system tables above to attribute spend per agent.

Where do the semantic layer and the catalog fit?

The vendors’ own advice is consistent: raw SQL on raw tables is the weakest way to answer a business question. We cover the reasons in detail in AI in BI: why agentic analytics needs a semantic layer first. If your metrics already live in dbt, the agent can use them through the dbt MCP server, whose remote version exposes Semantic Layer, SQL and discovery tools depending on your dbt platform plan.

The same principle drives Lightdash+. Its Ask Your Metrics add-on never writes raw SQL: it composes a Lightdash query, so answers inherit your governed dbt metric definitions, each question runs as the person asking, and it works with your own LLM on any OpenAI-compatible endpoint.

Agents also need to know which tables exist, who owns them, whether a column holds personal data and what breaks if something changes. The DataHub MCP server can be self-hosted against open-source DataHub Core and covers search, schema, ownership, tags and column-level lineage. Its mutation tools (tags, owners, descriptions) are off unless you set TOOLS_IS_MUTATION_ENABLED=true, which is the right default. Metadata only helps if it exists, though: an agent reading empty descriptions has nothing to reason with. DataHub+ runs open-source DataHub in your own tenancy, with an AI documentation plugin that drafts descriptions on your own LLM and lands them as proposals for review.

A rollout sequence that holds up

1. Pick one domain with an owner, a semantic model and real questions. Build the evaluation set before the server.
2. Stand up the governed tool only (Cortex Agent, Genie One or Conversational Analytics), with per-user OAuth, for a small group.
3. Add a catalog MCP with read-only tools, and fix the documentation gaps it exposes.
4. Give engineers a separate read-only SQL server on development data, with its own role, compute and budget.
5. Widen access only when accuracy per question type, audit coverage and cost per answer meet thresholds you agreed in advance.

If you are designing agent access to Snowflake, Databricks or BigQuery and want a second opinion on identity, tool scope or the semantic layer underneath, talk to the people who build it. Our Data & AI practice designs, builds and runs these platforms.