How to Connect ChatGPT to Snowflake (Step-by-Step)

You can connect ChatGPT to Snowflake without copying data into ChatGPT or handing it an administrator password. The clean setup uses a Snowflake-managed Model Context Protocol (MCP) server, Snowflake OAuth, and a narrow Snowflake role.

The Snowflake side is similar to a Claude-to-Snowflake connection, but the ChatGPT setup lives in Developer Mode. There is also one important trap: a successful Snowflake login does not prove ChatGPT can run a query. The user still needs a usable default role, default warehouse, and access to every object in the MCP path.

Here is the setup from end to end.

What you are actually connecting

ChatGPT connects to a remote Snowflake MCP server over HTTPS. It does not receive unrestricted access to the entire Snowflake account.

ChatGPT
  -> Snowflake OAuth security integration
  -> Snowflake user and default role
  -> Snowflake-managed MCP server
  -> approved Snowflake tools and data

Snowflake remains responsible for authentication, roles, warehouses, object grants, and query history. ChatGPT can only use the tools and data that the signed-in Snowflake user is allowed to access.

What you need before you start

Collect these values before creating the ChatGPT connector:

ChatGPT field	Where it comes from
Connector name	A label you choose, such as Company Snowflake
MCP server URL	Your Snowflake account URL plus the database, schema, and MCP server name
Authentication	OAuth
OAuth client ID	A Snowflake OAuth security integration
OAuth client secret	The same Snowflake OAuth security integration
OAuth callback URL	ChatGPT displays this while you create the connector
Snowflake login	Each person's normal Snowflake or SSO identity

The account identifier, MCP object names, OAuth credentials, and employee login are different values. Do not use a Snowflake username as the OAuth client ID or guess the MCP URL from the connector name.

1. Find the Snowflake account URL

Run this in Snowflake:

SELECT
  CURRENT_ORGANIZATION_NAME() AS organization_name,
  CURRENT_ACCOUNT_NAME() AS account_name,
  CURRENT_ACCOUNT() AS account_locator,
  CURRENT_REGION() AS region;

For a normal public Snowflake account, the preferred hostname uses the organization and account names:

https://<organization_name>-<account_name>.snowflakecomputing.com

If either name contains an underscore, replace it with a hyphen in the hostname. Use this Snowflake hostname—not the Snowsight browser address—as the base of the MCP URL.

2. Find the database, schema, and MCP server name

An administrator can list the available servers with:

SHOW MCP SERVERS IN ACCOUNT;

Suppose the server is named CHATGPT_MCP and lives in ANALYTICS.PUBLIC. The full endpoint is:

https://<organization>-<account>.snowflakecomputing.com/api/v2/databases/ANALYTICS/schemas/PUBLIC/mcp-servers/CHATGPT_MCP

The database, schema, and MCP server are real Snowflake objects. Copy their names from Snowflake. If the server lives in PUBLIC, the role needs USAGE on that exact schema even if all of the business tables live somewhere else.

3. Create a least-privilege Snowflake role

Do not use ACCOUNTADMIN as ChatGPT's connector role. Create or reuse a narrow role for the approved reporting data.

For an MCP server in ANALYTICS.PUBLIC using REPORTING_WH:

USE ROLE SECURITYADMIN;

CREATE ROLE IF NOT EXISTS CHATGPT_ANALYST;

GRANT USAGE ON WAREHOUSE REPORTING_WH
  TO ROLE CHATGPT_ANALYST;

GRANT USAGE ON DATABASE ANALYTICS
  TO ROLE CHATGPT_ANALYST;

GRANT USAGE ON SCHEMA ANALYTICS.PUBLIC
  TO ROLE CHATGPT_ANALYST;

GRANT USAGE ON MCP SERVER ANALYTICS.PUBLIC.CHATGPT_MCP
  TO ROLE CHATGPT_ANALYST;

Then grant whatever the MCP tools themselves require. That could include access to a Cortex Agent, semantic view, Cortex Search service, function, procedure, or approved reporting tables.

For direct access to a reporting schema, a narrow example is:

GRANT USAGE ON SCHEMA ANALYTICS.REPORTING
  TO ROLE CHATGPT_ANALYST;

GRANT SELECT ON ALL TABLES IN SCHEMA ANALYTICS.REPORTING
  TO ROLE CHATGPT_ANALYST;

GRANT SELECT ON FUTURE TABLES IN SCHEMA ANALYTICS.REPORTING
  TO ROLE CHATGPT_ANALYST;

Keep the role at the approved reporting layer. Do not grant broad access to raw, finance, HR, or administrative data just to make the first test pass.

4. Start the connector in ChatGPT and copy its callback URL

Snowflake must allow ChatGPT's exact OAuth callback URL, so start in ChatGPT before creating the OAuth integration:

1. Open Settings in ChatGPT.
2. Open Connectors, then Advanced.
3. Enable Developer Mode.
4. Return to Settings > Connectors and choose Create.
5. Enter a name and the complete Snowflake MCP server URL.
6. Choose OAuth authentication.
7. Copy the callback or redirect URL ChatGPT displays.

Menu labels can vary by ChatGPT plan and workspace policy. In a managed workspace, an owner or administrator may need to allow Developer Mode or publish the connector before members can use it. Making the connector available does not give members the administrator's Snowflake permissions; each person still signs into Snowflake separately.

5. Create the Snowflake OAuth integration

Use the exact callback URL from ChatGPT as OAUTH_REDIRECT_URI:

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE SECURITY INTEGRATION CHATGPT_MCP_INTEGRATION
  TYPE = OAUTH
  OAUTH_CLIENT = CUSTOM
  ENABLED = TRUE
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = '<CHATGPT_CALLBACK_URI>'
  OAUTH_USE_SECONDARY_ROLES = NONE
  ALLOWED_ROLES_LIST = ('CHATGPT_ANALYST');

The callback must match exactly. A different hostname, path, or trailing character can stop OAuth before Snowflake permissions are tested.

Retrieve the client credentials:

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('CHATGPT_MCP_INTEGRATION');

The result contains oauth_client_id, oauth_client_secret, and a second secret that can be used for rotation. Enter the client ID and one active secret in ChatGPT. Treat the secret like a password; do not put it in documentation, source control, or a support ticket.

6. Set the user's default role and default warehouse

This is the most common reason a connector authenticates successfully but cannot query.

The account URL tells ChatGPT which Snowflake account to reach. The warehouse supplies the compute needed to run queries. They are separate settings.

First, choose the reporting warehouse and confirm the role can use it:

SHOW WAREHOUSES;

GRANT USAGE ON WAREHOUSE REPORTING_WH
  TO ROLE CHATGPT_ANALYST;

Then grant the role to the user and set both defaults:

USE ROLE USERADMIN;

ALTER USER <USERNAME> SET
  DEFAULT_ROLE = CHATGPT_ANALYST
  DEFAULT_WAREHOUSE = REPORTING_WH;

USE ROLE SECURITYADMIN;

GRANT ROLE CHATGPT_ANALYST TO USER <USERNAME>;

Setting a role as the default does not grant that role. The user must have the role, and the role must have USAGE on the warehouse.

Snowflake's MCP OAuth flow commonly uses session:role:all. Despite the name, the session starts with the user's DEFAULT_ROLE; it does not automatically activate every role the user has. If DEFAULT_WAREHOUSE is blank—or the default role cannot use it—the OAuth screen can finish while the MCP session still fails to initialize.

You can also set these values in Snowsight under Governance & security > Users & roles. SQL is usually easier to review and repeat for multiple users.

7. Finish the connector in ChatGPT

Return to the connector form and enter:

• The connector name
• The complete Snowflake MCP server URL
• OAuth as the authentication method
• The OAuth client ID
• The OAuth client secret

Save the connector and complete the Snowflake authorization flow with the employee's own Snowflake or SSO account.

For a team workspace, repeat the Snowflake authorization for each person who needs the connector. Sharing the connector configuration does not mean sharing a Snowflake identity or role session.

Why “connected” can still mean “cannot query”

OAuth answers one question: did Snowflake authorize this user for this client? It does not prove the resulting session can reach the MCP server or run its tools.

When authentication succeeds but queries fail, check this path:

1. The user has the intended connector role.
2. That role has USAGE on the default warehouse.
3. The role has USAGE on the database and the MCP server's schema—including PUBLIC when that is where the server lives.
4. The role has USAGE on the MCP server.
5. The role can use the underlying agent, semantic view, service, function, procedure, or tables.
6. The user disconnected and reconnected after any Snowflake grants or defaults changed.

The reconnect matters because an existing OAuth token or session can preserve old context. A Snowflake permission change is not fully tested until ChatGPT reconnects and makes a new tool call.

Verify the real Snowflake session

Do not stop at the green connector status. Ask ChatGPT to run a harmless read-only query that shows the active session:

SELECT
  CURRENT_USER(),
  CURRENT_ROLE(),
  CURRENT_WAREHOUSE(),
  CURRENT_DATABASE(),
  CURRENT_SCHEMA();

Then run one narrow business query against an approved reporting object. A record count by month or a small aggregate with an obvious expected result is better than pulling sample rows from sensitive tables.

Before calling the connection complete, verify:

• OAuth consent completed.
• ChatGPT can see the intended MCP tools.
• CURRENT_ROLE() is the least-privilege connector role.
• CURRENT_WAREHOUSE() is the intended reporting warehouse.
• The role can use the database, MCP schema, MCP server, and underlying objects.
• A read-only business query returns a sensible result.

ChatGPT-to-Snowflake troubleshooting order

If the connector is present but unusable, check these in order:

1. MCP URL: Is it the full Snowflake hostname plus database, schema, and server path?
2. Callback URL: Does Snowflake contain the exact URL ChatGPT displayed?
3. Default warehouse: Is one set, and can the default role use it?
4. Default role: Is it the intended least-privilege role?
5. MCP path: Can that role use the database, schema, and MCP server?
6. Underlying objects: Can the role use everything the MCP tools depend on?
7. Fresh connection: Did the user reconnect after the Snowflake changes?
8. Network policy: If authorization itself fails, can OpenAI's infrastructure reach the Snowflake account under the current policy?

This order keeps authentication, session configuration, and object authorization separate. It also avoids the unsafe shortcut of widening the connector to an administrator role.

The main lesson is simple: a successful Snowflake login starts the verification; it does not finish it.

Need help setting up the MCP server, OAuth integration, or least-privilege role? See our Snowflake consulting services.

Sources: Snowflake-managed MCP server documentation, Snowflake user management, Snowflake account identifiers, and OpenAI developer documentation.