Cursor and Snowflake over MCP: two ways to set it up

Cursor can reach Snowflake through Snowflake's own managed MCP server, which you create as a schema object and secure with OAuth. Or you connect Snowflake to Contextflo once and give Cursor one URL. Pick the first for solo use, the second when a team will ask questions from their editors.

Option 1: Snowflake's managed MCP server in Cursor

Snowflake hosts MCP servers as schema objects. You create one with CREATE MCP SERVER ... FROM SPECIFICATION, and the specification exposes a SYSTEM_EXECUTE_SQL tool. The server URL follows this pattern:

https://<account-identifier>.snowflakecomputing.com/api/v2/databases/<DB>/schemas/<SCHEMA>/mcp-servers/<NAME>

OAuth goes through a SECURITY INTEGRATION ... TYPE = OAUTH that lists the client's redirect URI. OAuth cannot use ACCOUNTADMIN, so create a role for it. The full walkthrough, with semantic views, is in Claude and Snowflake semantic views.

Once the server exists, add it to ~/.cursor/mcp.json (global) or .cursor/mcp.json (one repo):

{
  "mcpServers": {
    "snowflake": {
      "url": "https://<account-identifier>.snowflakecomputing.com/api/v2/databases/<DB>/schemas/<SCHEMA>/mcp-servers/<NAME>"
    }
  }
}

Cursor runs the OAuth flow itself when the server needs it.

Option 2: Contextflo

Create a role and a user for Contextflo in Snowflake, with a small warehouse that suspends quickly:

• Role CONTEXTFLO_ROLE and user CONTEXTFLO_USER
• An XSMALL warehouse with AUTO_SUSPEND = 60
• USAGE on the database and schema
• SELECT on ALL and FUTURE tables and views
• Key-pair auth for the user

Set the public key with:

ALTER USER CONTEXTFLO_USER SET RSA_PUBLIC_KEY='...';

The FUTURE grants matter. If you forget them, new tables stay invisible.

In Contextflo, open Data Sources, then Add data source, and enter:

Pick tables, invite the team, then add Contextflo to Cursor:

{
  "mcpServers": {
    "contextflo": {
      "url": "https://mcp.contextflo.com/mcp"
    }
  }
}

Each person signs in with OAuth. Contextflo runs SELECT only, and the role underneath should be read-only too.

Snowflake's QUERY_HISTORY will show this SQL under the service user, not the person who asked. Contextflo's audit trail keeps the prompt and the SQL that ran for each person. It also generates table and column descriptions, stores your team's corrections as shared context, limits tables per person, and sends a weekly digest.

Which one to use

Only you, and you are happy to maintain a security integration? Option 1. If teammates will query from Cursor too, use Contextflo for shared context, per-person table access and the audit trail.

You do the modeling, we do the rest. Connect Snowflake free. Using Claude? See Claude with Snowflake.

FAQ

Can I use ACCOUNTADMIN to connect Cursor to Snowflake's MCP server? No. Snowflake's OAuth does not allow ACCOUNTADMIN, so create a dedicated role for the connection.

Why can't Cursor see my new Snowflake tables in Contextflo? Usually the FUTURE grants are missing. Grant SELECT on ALL and FUTURE tables and views, otherwise tables created later stay invisible.

Does Contextflo wake my Snowflake warehouse all day? Use an XSMALL warehouse with AUTO_SUSPEND = 60, as in the setup below, so it suspends after 60 seconds of idle time.

Can I see who asked what in Snowflake's QUERY_HISTORY? QUERY_HISTORY shows the SQL under the service user, not the person who asked. Contextflo keeps an audit trail of prompts and the SQL that ran, per person.