What Is the Snowflake MCP Server? Tools, Setup and Limits

The Snowflake MCP server, officially the Snowflake-managed MCP server, is a remote MCP server that runs inside a Snowflake account and lets AI agents use Snowflake data through the Model Context Protocol (MCP). It exposes Cortex Agents, Cortex Analyst, Cortex Search, SQL execution and custom functions as MCP tools, so an agent in Claude, Cursor or a custom application can ask questions of governed Snowflake data without anyone deploying separate infrastructure.

Snowflake made the managed server generally available on November 4, 2025, after a preview, and has extended it since, with External OAuth reaching general availability in July 2026. The details below reflect Snowflake's documentation as of November 2026. It is defined with SQL as an object in a database schema and governed by Snowflake's role-based access control.

What Is the Snowflake MCP Server?

Before managed servers, connecting an agent to Snowflake meant running an MCP server yourself, on a laptop or a container, holding Snowflake credentials and keeping it patched. The managed server moves that into the platform. Snowflake hosts the endpoint, authenticates the user and runs every tool call under that user's Snowflake role, so the same grants that protect a table in a worksheet protect it when an agent asks.

Snowflake describes three things the server provides: a standardized interface for tool discovery and invocation, authentication through Snowflake OAuth with optional External OAuth to the company's identity provider, and role-based access control over both the server and each tool. It builds on Snowflake Cortex, the platform's set of managed AI services, and on semantic views, which give Cortex Analyst the metrics, relationships and synonyms it needs to write accurate SQL.

Which Tools Does the Snowflake MCP Server Expose?

Each tool in the server specification has a type that maps to a Snowflake capability. Snowflake currently documents six:

Snowflake's own recommendation for business data is to expose one Cortex Agent as the client-facing tool. The agent is configured with the Analyst, Search and custom tools it needs, and the external client sees a single governed interface instead of a long list of low-level tools. Exposing Cortex Analyst or Cortex Search directly makes sense when the external client should choose between them itself. A SQL execution tool runs queries without Cortex Agent orchestration, and where users need different levels of data access and clients do not honor role scopes, Snowflake suggests separate MCP servers with dedicated roles.

How Do You Set Up a Snowflake MCP Server?

Setup takes three steps: create the server object, grant access, and point an MCP client at its URL.

1. Create the server

An MCP server is created in a database and schema with a YAML specification that lists its tools. This example exposes a single Cortex Agent, the pattern Snowflake recommends for business data:

CREATE OR REPLACE MCP SERVER analytics.sales.revenue_mcp
  FROM SPECIFICATION $$
  tools:
    - title: "Revenue analytics agent"
      name: "revenue_agent"
      type: "CORTEX_AGENT_RUN"
      identifier: "analytics.sales.revenue_agent"
      description: "Answers questions about bookings, revenue and churn."
  $$;

Tool names and descriptions matter more than they look. The MCP client picks a tool from its name and description, so precise, domain-specific wording is what makes an agent choose the right one when several are exposed. SHOW MCP SERVERS, DESCRIBE MCP SERVER and DROP MCP SERVER manage the object afterwards.

2. Grant access

Access to the server and access to its tools are separate. A dedicated role needs USAGE on the MCP server to connect and discover tools, then the privilege for each tool: USAGE on the agent, SELECT on a semantic view, USAGE on a search service or function, and the warehouse, database and schema grants that any query needs. Snowflake advises against granting the role to PUBLIC or opening all current and future tables just to support an MCP client.

3. Connect a client

The server is reached at an HTTPS endpoint of the form https://<account_url>/api/v2/databases/<database>/schemas/<schema>/mcp-servers/<name>. In the MCP client, you add it as a remote server and sign in through OAuth. Snowflake notes that hostnames should use hyphens rather than underscores, because MCP clients have connection issues with underscores.

How Do Authentication and Access Control Work?

The managed server follows the authorization approach recommended in the MCP specification, with a few Snowflake-specific details:

• Snowflake OAuth by default. A single OAuth security integration can serve every user and several MCP servers in an account, while each user still signs in with their own credentials.
• External OAuth. Since July 2026, servers can bind to an external identity provider such as Okta or Microsoft Entra ID, and administrators can configure which OAuth scopes, and so which primary roles, MCP clients discover.
• No dynamic client registration. Clients are registered through the security integration, so tools that rely only on dynamic registration need manual configuration.
• Roles. By default, a server advertises all roles and the OAuth session uses the user's DEFAULT_ROLE as its primary role, administrators can advertise specific role scopes instead, and Snowflake's recommended configuration leaves secondary roles disabled.
• Tool visibility. tools/list omits a Cortex Agent tool when the active role lacks USAGE on that agent, so users only see tools they can actually run.

Snowflake's documentation also lists security recommendations that apply to any MCP deployment: prefer OAuth to hardcoded tokens, give a Programmatic Access Token only the least-privileged role that works, verify the tools of any third-party MCP server before connecting it to guard against tool poisoning and tool shadowing, and rely on permissions rather than tool annotations for control. Snowflake does not validate that a tool behaves as its annotations claim, so permissions on the underlying objects remain the real boundary.

What Are the Limits of the Snowflake MCP Server?

The documented limits, as of November 2026, shape what the server is good for:

The last row describes the design rather than a shortcoming. The server is a gateway to Snowflake, and it does that job well. Snowflake is also widening what its catalog knows: Horizon Context, in preview since October 2026, adds metadata connectors for 18 external sources such as Power BI, Tableau and dbt. The tools an agent calls through the managed MCP server still run on Snowflake.

Snowflake MCP Server vs a Catalog MCP Server

Organizations that run Snowflake alongside BI tools, transformation code, other platforms and operational systems usually end up with more than one MCP server. The two most common kinds answer different questions.

They work well together. An agent can look up the approved definition of "net revenue retention" and its owner in the catalog, confirm which semantic view implements it, and then ask the Snowflake server for the number. The catalog keeps the definition consistent with how finance reports it in Power BI or how the metric is built in dbt, which is context that sits outside any single platform.

Where Business Context Comes From

Cortex Analyst is only as accurate as the semantic views behind it, and a Cortex Agent only as reliable as its instructions and tools. Those definitions have to come from somewhere, and in most companies they already exist in more than one place. A context layer for Snowflake keeps them governed in one place and connects them to the rest of the stack.

Dawiso works with Snowflake in both directions. It catalogs Snowflake semantic views alongside the tables they are built on, and it can export selected data products as an Open Semantic Interchange (OSI) semantic model YAML file, with a Snowflake variant among the export formats. The workflow, including how Cortex agents appear in lineage, is described in governing Snowflake Cortex agents and semantic views. The Dawiso MCP server then serves the glossary, ownership, classifications and lineage to any MCP-compatible agent, alongside the Snowflake-managed server. For a closer look at what agents gain from a catalog over MCP, see what an MCP server on a data catalog gives AI agents.

Conclusion

The Snowflake-managed MCP server is the shortest path from an AI agent to governed Snowflake data. It needs no extra infrastructure, inherits Snowflake's roles and OAuth, and turns Cortex Agents, Analyst, Search and SQL into tools any MCP client can call. Its design keeps it focused on Snowflake, with a cap of 50 tools per server and support for tools only. For agents that also need to know what the data means, who owns it and how it connects to the rest of the business, pair it with a cross-platform catalog served over MCP.

Sources

• Snowflake Documentation - Snowflake-managed MCP server (tool types, privileges, OAuth, security recommendations, limitations)
• Snowflake Documentation - Nov 04, 2025: Snowflake-managed MCP server (General availability)
• Snowflake Documentation - Jul 22, 2026: External OAuth and configurable scopes for MCP servers (General availability)
• Snowflake Documentation - Oct 12, 2026: Horizon Context (Preview)
• Model Context Protocol - Specification, Authorization