It took me a month to connect Snowflake to Claude's web connector. The setup is genuinely complex — the most involved MCP configuration I've encountered. But the real challenge wasn't the complexity. It was finding the right information in documentation that assumes you're building something far more elaborate than what I needed.
Snowflake has extensive docs. Pages covering Cortex Agents, semantic models, Python connectors, local MCP servers. What's missing is a simple guide: "Here's how to connect Claude.ai to your Snowflake data."
This is that guide.
Why Not Cortex Agent?
Snowflake offers Cortex Agent — their own agentic experience for querying your data. It runs within Snowflake's boundary, uses their hosted models, and keeps everything inside their ecosystem.
I see this pattern everywhere. Companies aren't building AI integrations. They're building AI features — their own chat interfaces, their own agents, their own "ask questions about your data" experiences.
The problem? My data will never live entirely in one place.
I have data in Snowflake. I also have docs in Google Drive, tickets in Jira, conversations in Slack, emails in Outlook. Snowflake's Cortex Agent can't see any of that. Neither can any other vendor's isolated AI feature.
Claude, on the other hand, connects to all of them. It becomes the hub — the single interface where I can ask questions that span systems. That's the value proposition. Not another discrete chat experience, but a connector that plugs into where I already work.
So when I saw Snowflake's MCP connector in Claude's marketplace, I expected a straightforward setup. OAuth credentials, a few clicks, done.
Instead, I got a 404 error.
The Missing Pieces
The documentation exists — that's not the problem. The problem is that it's written for building Cortex Agents with semantic models, not for connecting Claude.ai's web connector via OAuth.
After a support ticket, weeks of back-and-forth, and eventually pointing Claude's Research mode at the problem for 20 minutes, I found what I needed:
The redirect URI:
https://claude.ai/api/mcp/auth_callback
The Server URL format:
https://<org>-<account>.snowflakecomputing.com/api/v2/databases/<DB>/schemas/<SCHEMA>/mcp-servers/<MCP_SERVER_NAME>
These two pieces took the longest to find. Nobody I could reach at Snowflake support knew them — and apparently, they didn't know anyone who did either. Claude found them buried in reference documentation that wasn't linked from anywhere obvious.
The Setup
The full SQL script is in this gist. Here's what it does:
- Creates a role for Claude access
- Grants that role to all users via PUBLIC
- Creates an OAuth security integration with the correct redirect URI
- Creates the MCP server
- Retrieves the credentials you'll enter in Claude's connector screen
Run the script, grab the Server URL and OAuth credentials, paste them into Claude's Snowflake connector.
The Gotchas
A few things I learned the hard way:
OAUTH_USE_SECONDARY_ROLES must be IMPLICIT. Setting it to NONE causes silent connection failures — no error message, just "not connected" after authenticating.
PRE_AUTHORIZED_ROLES_LIST should be empty. Otherwise users whose default role isn't in the list get "Invalid Consent Request" errors with no explanation.
Multi-user "Invalid Consent" errors: Check the failing user's default role. If it's a blocked role like ACCOUNTADMIN, they'll fail silently.
Underscores in account names must become hyphens in the Server URL. If your Snowflake account name contains underscores (like TEST_ACCOUNT), OAuth will fail silently. Replace underscores with hyphens in the URL only — so MYORG-TEST-ACCOUNT.snowflakecomputing.com, not MYORG-TEST_ACCOUNT. Your actual account name stays unchanged; this is just a URL formatting quirk. (Thanks to a reader who figured this one out and shared it.)
The gist includes comments explaining each one.
The Caveat You Need to Know
Here's the one thing that concerns me: you cannot enforce read-only access.
Because OAUTH_USE_SECONDARY_ROLES must be IMPLICIT, all of a user's Snowflake roles activate as secondary roles. Even if you set the primary role to a read-only role, the effective permissions are the union of all roles. If any role has write access, Claude has write access.
I tested this. With my primary role set to read-only, DELETE commands still executed successfully.
In the agentic era, this matters. Things can get out of hand quickly. And when it comes to data, mistakes are usually irreversible — or at the very least, painful to revert. I want to rule that out entirely before rolling this out broadly.
On the flip side, I'm pretty sure our Data Engineers would be thrilled if they could tell Claude to create tables, manage schemas, run DDL — and it just worked. The write access isn't inherently bad. It just needs to be intentional.
This isn't a Snowflake limitation — it's a gap in Claude's connector. It doesn't pass a role scope in OAuth requests, which would allow Snowflake to restrict to a single role. I've filed a feature request with Anthropic.
Until this is fixed, know what permissions your users have before enabling this connector.
The Payoff
Once connected, the experience is excellent. Claude gets a simple "run SQL" tool. No semantic models to configure, no Cortex setup, no agent frameworks. Just ask questions about your data and Claude queries it directly.
The vision is straightforward: everyone in my company will be able to ask questions about the data they have access to. It doesn't matter how skilled they are with SQL or how familiar they are with the schema. They call it "democratizing data" — and in this case, it actually is.
Combined with Claude's other integrations — Drive, Jira, Slack, Outlook — you get something no isolated AI feature can offer: a single interface that spans your entire stack.
That's the integration I wanted. It just shouldn't have taken a month to set up.
