> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mindset.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Snowflake Native MCP Setup Guide

> Everything you need to connect a Snowflake-managed MCP server to Mindset AI, including configuration notes and validation steps to get set up smoothly.

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`.

<Info>
  For zero-parameter tools, an empty schema is sufficient:

  ```yaml theme={null}
  input_schema:
    type: "object"
    properties: {}
  ```
</Info>

### 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](#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.

<Warning>
  The PAT value is returned only once at creation time and cannot be retrieved afterward. Store it securely immediately.
</Warning>

## 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

```bash theme={null}
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:

```bash theme={null}
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

| Symptom                                             | Likely cause                                                                                                                                                |
| --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tools/list` returns an empty array                 | Missing `input_schema` in the tool config, or the connecting role lacks `USAGE` on the tool's backing procedure/function                                    |
| `does not exist or not authorized`                  | The MCP server was replaced and the `USAGE` grant was not re-applied                                                                                        |
| `Unknown tool type: CUSTOM`                         | Use `GENERIC` instead of `CUSTOM` for stored procedure and UDF tools                                                                                        |
| `Network Policy is required`                        | SERVICE-type users need a network policy assigned before a PAT can be created                                                                               |
| Tool listed but invocation fails                    | The connecting role may lack `SELECT` on tables queried by the procedure (relevant for `EXECUTE AS CALLER` procedures)                                      |
| SSL `CERTIFICATE_VERIFY_FAILED` / hostname mismatch | Account name contains underscores in the hostname — replace underscores with hyphens in the URL (see [Key setup considerations](#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.