Skip to main content
Sidecar provides native setup for Snowflake MCP. The Agent Console reuses the Snowflake-managed MCP server created for Ask Sidecar, but it authenticates with an organization-wide service-user token.
A personal PAT on the Ask Sidecar tab applies only to that person. The PAT on the MCP tab is shared by Agent Console jobs. Use a service user for the Agent Console credential.

​
Before you start

You need: The Sidecar setup creates SIDECARMCPSERVER in the PUBLIC schema of your selected Sidecar database. It exposes one executesql tool with Snowflake’s read_only option enabled. See Snowflake’s CREATE MCP SERVER reference for the underlying object and tool specification.

​
Configure network access

Snowflake requires service users who authenticate with Programmatic Access Tokens to be subject to a network policy with at least one network rule by default. Sidecar sends Snowflake MCP requests from this production outbound IP address:
Check whether a user-level or account-level network policy applies to the service user. A user-level policy overrides an account-level policy.
If a policy applies, inspect whether it uses network rules or the legacy IP allowlist:
For a rule-based or new policy, create a network rule for Sidecar in the database that contains SIDECARMCPSERVER:
If you created SIDECAR_MCP_INGRESS during Ask Sidecar setup, reuse it and skip the CREATE NETWORK RULE statement.
Add the rule to an existing rule-based policy without replacing its other rules:
If DESCRIBE NETWORK POLICY shows ALLOWED_IP_LIST instead of ALLOWED_NETWORK_RULE_LIST, do not add the Sidecar rule to that legacy policy. Snowflake requires network rules for PAT access and recommends against mixing legacy IP lists with network rules. Create a rule-based user policy that reproduces every restriction the service user needs, then add the Sidecar rule and attach the new policy. If no rule-based policy applies, create a dedicated policy and attach it to the service user:
If you use a different service user, replace SIDECAR_USER with its name. See Snowflake’s programmatic access token guide and network policy guidance.

​
Create the organization PAT

You can reuse the SIDECAR_USER service user from the Snowflake integration setup, or create a separate service user with narrower data access. The following example creates a 90-day PAT for the existing Sidecar service user and restricts it to SIDECAR_ROLE:
Copy the token_secret value from the result. Snowflake shows it only once. Change the expiration to comply with your authentication policy. Snowflake requires a role restriction for service-user PATs by default. Your authentication policies must also allow PROGRAMMATIC_ACCESS_TOKEN as an authentication method. See Snowflake’s programmatic access token guide for authentication policy requirements, token generation, and rotation.

​
Enable Snowflake MCP in Sidecar

  1. In Sidecar, select Integrations.
  2. Open Snowflake, then select the MCP tab.
  3. Click Enable MCP.
  4. Paste the service user’s PAT into Service account PAT (organization-wide).
  5. Click Add server.
Sidecar derives the endpoint from the Snowflake account identifier and the database selected during MCP server setup. It then connects to the server and discovers its tools.

​
Finish agent setup

Registering the server does not give it to an agent automatically. Grant the Snowflake MCP server to an agent and select it for jobs. Rotate the PAT before it expires. In Integrations → MCP Servers, open the Snowflake row and select Replace token.

​
Troubleshooting

Complete the Snowflake MCP admin setup on the Ask Sidecar tab. Run the generated SQL, then click Verify MCP Server before returning to the MCP tab.
Confirm that the token belongs to a service user, its role restriction names a role granted to that user, and the token has not expired. Confirm that the effective network policy allows 44.236.246.98/32 and that the authentication policy permits PROGRAMMATIC_ACCESS_TOKEN.
The PAT’s restricted role controls data access. Grant that role USAGE on the required warehouse, database, and schemas, plus SELECT on the required tables and views. Do not grant broader access than the agents need.