Skip to main content
Book a demo

Connect Snowflake to Cursor

Give Cursor governed access to Snowflake’s 8 tools through Runlayer, with identity, policy, scanning, and audit on every call.

Book a demo Cursor setup guide

Set up

Add Snowflake to Cursor in four steps

Admins approve the server once. Everyone in Cursor then gets it through the same governed connection.

  1. 1

    Approve Snowflake in Runlayer

    Add Snowflake from the catalog and choose who can use it and which of its tools are allowed.

  2. 2

    Connect Cursor to Runlayer

    Runlayer’s CLI installs the Runlayer Plugin natively in Cursor, and admins can roll it out org-wide with Auto Sync plus a Cursor team rule. With direct tool listing turned on for your deployment, Snowflake’s 8 tools show up in Cursor’s own tool list.

    Cursor setup guide
  3. 3

    Sign in to Snowflake

    Each user signs in to Snowflake with OAuth. Runlayer keeps the tokens out of the client’s configuration.

  4. 4

    Use Snowflake from Cursor

    Snowflake’s approved tools appear in Cursor. Every call is checked against policy and recorded.

Tools

8 Snowflake tools in Cursor

Runlayer policy decides which of these Cursor users can call.

  • Describe semantic view

    Describe a semantic view.

  • Get semantic view ddl

    Get the DDL for a semantic view.

  • List semantic views

    List all semantic views in the account, database, or schema.

  • Query semantic view

    Writes and runs a statement to query a semantic view using DIMENSIONS, METRICS, and/or FACTS.

  • Run Snowflake query

    Run a SQL query in Snowflake.

  • Show semantic dimensions

    Show all semantic dimensions in the account, database, or schema.

  • Show semantic metrics

    Show all semantic metrics in the account, database, or schema.

  • Write semantic view query tool

    Writes a query statement to query a semantic view using DIMENSIONS, METRICS, and/or FACTS.

Control

What Runlayer can see and stop in Cursor

Some controls apply to every client at the gateway. Others depend on what Cursor exposes to Runlayer.

  • Gateway policy (available)

    Every Snowflake call from Cursor passes through Runlayer, where your policies can allow, alert, mask, or block it.

  • Audit trail (available)

    Each call is recorded with the user, Cursor as the client, the tool, and the policy and scanner decisions.

  • Client hooks (available)

    Capture supported prompts, reasoning, local and MCP tool calls, responses, and scanner decisions in real time.

  • Stop a call before it runs (available)

    Runlayer can deny a tool call before Cursor runs it, including calls to MCP servers.

  • Block output after it runs (available)

    Runlayer can block a tool’s output before Cursor’s model sees it.

  • Redact output in place (not available)

    Cursor cannot take masked output, so Runlayer can block a tool’s output but not mask it. The gateway still applies policy to the call.

In Cursor

  • Runlayer cannot tell Agents Window sessions apart from regular IDE sessions.
  • The Cursor CLI sends fewer session events than the IDE, but Runlayer’s allow and deny decisions still apply.

Frequently asked questions

Connect more

Find another combination