Snowflake’s MCP server connects an agent to your warehouse. It is aimed at the same job as the BigQuery server, with the difference that Snowflake’s role and warehouse model gives you more direct control over both what the agent can see and what its curiosity costs.
What it actually does
Snowflake’s official server is a Snowflake-managed MCP server object that you create in your own account, reached at an account URL of the form https://<account_url>/api/v2/databases/{database}/schemas/{schema}/mcp-servers/{name}. It authenticates with Snowflake OAuth, optional External OAuth, or programmatic access tokens. You choose which tools it exposes, from Cortex Agents, Cortex Analyst (semantic views), Cortex Search, SQL execution, and custom functions or stored procedures, up to 50 tools per server. Because it acts as the role you configure, your existing governance should continue to apply.
Practical patterns:
- ‘Run a query for revenue by region this quarter through the SQL tool.’
- ‘Compare revenue by region this quarter against the same quarter last year.’
- ‘Ask my Cortex Analyst semantic view which regions grew fastest last year.‘
Why use it
Warehouses hold the authoritative version of the numbers, and the gap between having them and being able to ask about them is usually SQL plus tribal knowledge of the schema. An agent that can use your semantic views or run SQL closes both. The governance model is what makes this safer than it sounds: unlike a shared credential in a notebook, a scoped role means the agent genuinely cannot see what it should not.
Gotchas
Compute is the cost to watch. Every query the agent runs spins a warehouse, and an agent iterating towards the right query will run several. Point it at a small warehouse with a short auto-suspend rather than the one your dashboards use. Create a dedicated role rather than reusing an analyst’s, since the whole safety argument depends on that scoping being real. And large result sets consume context quickly, so steer towards aggregates.
