Skip to main content
This lesson shows how to adapt a churn-detection LLM agent to work with Snowflake through the MCP Toolbox. The agent logic and instructions stay the same as other warehouse integrations — the key change is pointing the MCP Toolbox at the Snowflake adapter and ensuring the toolbox can authenticate using SNOWFLAKE_* environment variables.
Ensure you have a .env file (or environment variables) with the required keys for KodeKey and Snowflake: KODEKEY_BASE_URL, KODEKEY_API_KEY, and SNOWFLAKE_ACCOUNT, SNOWFLAKE_USER, SNOWFLAKE_PASSWORD (or PAT), SNOWFLAKE_DATABASE, SNOWFLAKE_SCHEMA, SNOWFLAKE_WAREHOUSE, SNOWFLAKE_ROLE. If you use a custom toolbox path, set TOOLBOX_BIN. The MCP Toolbox reads the SNOWFLAKE_* variables to authenticate when launched.

Consolidated example script

The script below is a cleaned and consolidated example that highlights the important pieces and where they belong:

What changed for Snowflake (MCP specifics)

  • The core agent, model, and instruction text remain the same as other warehouse integrations (BigQuery, Databricks, etc.).
  • The MCP Toolbox is started with arguments that select the Snowflake adapter/prebuilt configuration. That change is effectively a single adapter/arg swap in the toolbox/server parameters.
  • The toolbox process reads the SNOWFLAKE_* environment variables for authentication; by calling load_dotenv() and passing os.environ into the toolbox subprocess environment, the toolbox can authenticate with Snowflake automatically.

Environment variables

Do not commit credentials to source control. Use environment variables, secrets managers, or CI/CD vaults for production deployments. If you are sharing logs, sanitize SNOWFLAKE_PASSWORD and API keys.

UI screenshots referenced in this lesson

A Databricks web UI showing the Catalog Explorer with a selected table named "support_tickets." The right pane displays sample rows and columns (ticket_id, customer_id, category, priority, sentiment, resolution_hours, resolved, created_date) from the support tickets dataset.
In Databricks demos we typically expose the support tickets dataset (joined to customer_features) so the agent can distinguish friction (support issues) from disengagement signals.
A screenshot of the Snowflake web UI showing the Database Explorer on the left and a data preview of a table named "CUSTOMER_FEATURES" on the right, with columns like CUSTOMER_ID, REGION, UPGRADE_ELIGIBLE, and usage/support metrics. The table displays rows of customer records and attributes.
The CUSTOMER_FEATURES table contains the per-customer signals referenced in the agent instruction. The TABLE variable in the script points to this fully qualified table (database.schema.table).
A screenshot of the Snowflake web UI showing the Database Explorer/Horizon Catalog on the left and a data preview of a BILLING_ACCOUNTS table on the right, listing customer IDs, plan tiers, monthly revenue, contract start/end dates, and payment status.
Billing and plan-tier data (from a separate table) can be surfaced to improve retention recommendations — e.g., prioritize enterprise accounts or those that are upgrade-eligible.

Running the script

Execute the demo locally:
A successful run typically prints a structured agent reply describing:
  • Risk level (low / medium / high)
  • The signals the model cited (e.g., low recent usage, negative usage trend, high support tickets)
  • Positive indicators (e.g., plan tier, upgrade eligibility)
  • A recommended retention action
Example (cleaned) response excerpt:
  • Risk level: medium
  • Signals:
    1. Low tenure (e.g., 2 months)
    2. Declining engagement (usage_delta_30d: -15%)
    3. Moderate recent usage (usage_last_30d: 85) — combined with the negative trend suggests waning adoption
  • Positive indicators:
    • Low support friction (2 tickets in 90 days)
    • Enterprise plan tier
    • Upgrade eligible
  • Recommended Retention Action: Schedule a proactive business-review call within 1–2 weeks to investigate the usage decline and present a tailored success plan; given enterprise status and upgrade eligibility, position the discussion as value-driven rather than purely reactive.

Cleanup warnings you may see

You might see a non-fatal cleanup warning in some ADK/toolbox versions when the MCP stdio session is torn down. Example: Warning: Error during MCP session cleanup for stdio_session: Attempted to exit cancel scope in a different task than it was entered in This usually appears during subprocess/session cleanup and does not necessarily indicate the agent failed. If the agent produced the expected output, the run was successful.

Summary and best practices

  • The agent logic and instructions are portable across warehouses; only the MCP Toolbox adapter/args change to target a different warehouse (Snowflake in this demo).
  • Make sure SNOWFLAKE_* environment variables are available to the toolbox subprocess so it can authenticate and expose the SQL tool.
  • Use the MCP prebuilt Snowflake configuration or the proper adapter flag in StdioServerParameters when constructing McpToolset.
  • Keep secrets out of source control; use environment management or secret stores for production.

Watch Video