Skip to main content
This guide covers the key setup steps and configuration details for connecting a Snowflake-managed MCP server to the Mindset AI platform. Some of this may be familiar if you’ve worked with Snowflake MCP servers before — we’ve included it to help you navigate potential challenges and get connected as quickly as possible.

​
How Mindset AI connects

Mindset AI connects to your MCP server using a Programmatic Access Token (PAT) passed as a Bearer token in the Authorization header. No OAuth configuration is needed on the Mindset AI side. You manage the Snowflake setup entirely; we just need the endpoint URL and the PAT.

​
Key setup considerations

The following are the most important things to get right during setup. Each one has clear diagnostic steps if something doesn’t look right.

​
Tool type naming

When defining stored procedure or UDF tools in your MCP server specification, the tool type must be GENERIC. Some Snowflake documentation references CUSTOM as the type name, but the runtime does not accept it. Use GENERIC for all stored procedure and UDF tools.

​
input_schema is required for all tools

Every tool in the MCP server specification must include an input_schema in its config block, even if the procedure or function takes no parameters. Without it, the tool will not appear when clients call tools/list.
For zero-parameter tools, an empty schema is sufficient:
input_schema:
  type: "object"
  properties: {}

​
Permissions are multi-layered

The role associated with the PAT needs access at three independent layers:
  1. MCP server access — the role must have USAGE on the MCP server object itself
  2. Tool object access — the role must have USAGE on each tool’s backing procedure or function
  3. Data access — if a procedure uses EXECUTE AS CALLER, the role also needs SELECT on the underlying tables
If any layer is missing, the tool will be excluded from tools/list or fail at invocation. The Troubleshooting reference below covers how to identify which layer to check.

​
Re-apply grants after replacing the MCP server

Running CREATE OR REPLACE MCP SERVER creates a new object, which means all previously granted permissions on the old object are lost. After every replace, re-apply the USAGE grant on the MCP server. Without it, connecting clients will receive a does not exist or not authorized error.

​
SERVICE users require a network policy for PAT generation

Snowflake requires a network policy to be assigned to a SERVICE-type user before a PAT can be generated. For initial testing, an open network policy works; for production, restrict to the IP ranges relevant to the connecting service.

​
Use hyphens instead of underscores in account hostnames

If your Snowflake account name contains underscores (e.g., myorg-my_account), replace them with hyphens in the hostname portion of the MCP endpoint URL. Most SSL libraries require this because underscores are not valid hostname characters under RFC 952, and the SSL certificate will only match the hyphenated form. For example: 
https://myorg-my-account.snowflakecomputing.com/api/v2/databases/...
Snowflake resolves both forms to the same account, but only the hyphenated version will match the SSL certificate. Note that curl may succeed with underscores while the Mindset AI platform connection does not, so it’s worth double-checking the URL format regardless.

​
PAT lifecycle and rotation

PATs have a maximum lifetime of 365 days and cannot be refreshed. Plan for rotation ahead of expiry and make sure the team responsible for the Snowflake account knows when the token was created.
The PAT value is returned only once at creation time and cannot be retrieved afterward. Store it securely immediately.

​
Validate before connecting to Mindset AI

We recommend verifying your MCP server works end to end before sharing connection details with the Mindset AI team. Validating upfront means that if anything needs adjusting, it’s straightforward to identify — once the connection goes through the Mindset AI agent pipeline, MCP is one of several layers, so it’s much easier to resolve issues before that point. A couple of curl calls take under a minute.

​
Step 1: Verify tool discovery

MCP_URL="https://<account>.snowflakecomputing.com/api/v2/databases/<DB>/schemas/<SCHEMA>/mcp-servers/<SERVER_NAME>"
PAT="<your_pat_value>"

curl -s -X POST "$MCP_URL" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $PAT" \
  -d '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}'
You should see every tool you defined, with its name, description, and input schema. If the tools array is empty, check for a missing input_schema in the tool spec or a missing permission on the tool’s backing object.

​
Step 2: Verify each tool is callable

For each tool returned by tools/list, invoke it and confirm it returns the expected data: 
curl -s -X POST "$MCP_URL" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $PAT" \
  -d '{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {"name": "<tool-name>", "arguments": {}}}'
The response should contain "isError": false and the expected result. If the tool takes parameters, include them in the arguments object. Both steps should pass before sharing connection details with Mindset AI.

​
What Mindset AI needs from you

Once both validation steps pass, provide the Mindset AI team with:
  1. MCP endpoint URL — https://<account>.snowflakecomputing.com/api/v2/databases/<DB>/schemas/<SCHEMA>/mcp-servers/<SERVER_NAME>
  2. PAT value — the token string
These are registered in the Mindset AI Agent Management Studio (AMS) as an external MCP server. The PAT is stored as the API key. On the Mindset AI side, the PAT is held in GCP Secret Manager and is never exposed to end users.

​
Troubleshooting reference

SymptomLikely cause
tools/list returns an empty arrayMissing input_schema in the tool config, or the connecting role lacks USAGE on the tool’s backing procedure/function
does not exist or not authorizedThe MCP server was replaced and the USAGE grant was not re-applied
Unknown tool type: CUSTOMUse GENERIC instead of CUSTOM for stored procedure and UDF tools
Network Policy is requiredSERVICE-type users need a network policy assigned before a PAT can be created
Tool listed but invocation failsThe connecting role may lack SELECT on tables queried by the procedure (relevant for EXECUTE AS CALLER procedures)
SSL CERTIFICATE_VERIFY_FAILED / hostname mismatchAccount name contains underscores in the hostname — replace underscores with hyphens in the URL (see Key setup considerations)

​
Who can see what: access scoping

Snowflake native MCP servers are an excellent fit for exposing data that should be available to all users interacting with a particular agent — product catalogs, company reference data, reporting dashboards, knowledge bases. These are strong fits because the data is the same regardless of who is asking. Snowflake native MCP servers authenticate using a single PAT tied to a single Snowflake role. That role determines what data the tools can access. On the Mindset AI side, you control which agents (and therefore which users) can reach the MCP server through entitlement configuration. Within the MCP server itself, all requests use the same role and data access. Mindset AI sends user identity headers (x-user-id, x-session-tags) on every request. With custom-built MCP servers these headers enable per-user data filtering. Snowflake’s managed MCP server does not currently pass these headers through to stored procedures, so tools cannot tailor their responses based on which end user is asking. This is expected to be addressed in a future Snowflake release — the MCP protocol already defines a mechanism for passing client metadata to tools (the _meta field), and Snowflake is anticipated to adopt it, at which point per-user scoping within Snowflake native MCP servers will be possible without any custom code.

​
Planning for different access levels

If you have tools that should only be available to certain user groups (for example, managers vs. individual contributors), you can create separate Snowflake MCP servers with separate PATs and roles. Each server is registered independently in the Mindset AI AMS and entitled to the appropriate agents, keeping tool visibility aligned with user roles. For use cases that require per-user data filtering today — where different users should see different rows from the same table — a custom MCP server is the better fit. The Mindset AI team can advise on the right approach for your situation.

​
Additional notes

Tool descriptions are used by the Mindset AI agent to decide when to call a tool. Clear, specific descriptions lead to better tool selection. If an agent isn’t calling a tool when expected, reviewing and tightening the tool description is usually the most effective first step.