Skip to main content
Glama
snowflake-cost-mcp

snowflake-cost-mcp

by alizubairs

snowflake-cost-mcp

An MCP server that gives Claude (or any MCP-speaking agent) direct, read-only visibility into Snowflake warehouse cost and query performance — credit usage by warehouse, the most expensive queries in a window, and heuristic right-sizing recommendations.

Why this exists (and what it deliberately doesn't do)

Snowflake already ships an official, actively-developed managed MCP server covering schema browsing, Cortex Analyst/Search, and general query execution — and several community servers cover similar ground. This project intentionally does not duplicate any of that. It exists for the one thing none of them focus on: cost attribution and performance right-sizing, using Snowflake's ACCOUNT_USAGE views.

Use this alongside the official Snowflake MCP server, not instead of it.

Related MCP server: MCP Server

Tools

Tool

What it does

list_warehouses

Warehouse inventory: size, auto-suspend/resume, running/queued queries

get_warehouse_credit_usage

Credits consumed per warehouse over a lookback window

find_expensive_queries

Slowest/costliest successful queries in a window

get_query_detail

Full detail for one query by QUERY_ID

get_warehouse_right_sizing_recommendations

Heuristic oversized/undersized/no-signal call per warehouse

run_readonly_query

Ad-hoc SELECT-only escape hatch — disabled by default

ACCOUNT_USAGE views are eventually consistent (Snowflake documents up to ~45 minutes–a few hours of latency), so treat results as "recent history," not real-time.

Prerequisites

You need a Snowflake role that can read ACCOUNT_USAGE. Create a dedicated, least-privilege role rather than reusing ACCOUNTADMIN:

CREATE ROLE IF NOT EXISTS mcp_cost_monitor;
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE mcp_cost_monitor;
GRANT USAGE ON WAREHOUSE compute_xs TO ROLE mcp_cost_monitor;
GRANT ROLE mcp_cost_monitor TO USER your_service_user;

This role can read account usage metadata and nothing else — no write grants anywhere. That's the real security boundary; the in-code SQL guard is a backup, not a substitute for this.

Setup

1. Install

pip install -e .
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt
openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub
ALTER USER your_service_user SET RSA_PUBLIC_KEY='<contents of rsa_key.pub, header/footer stripped>';

Copy .env.example to .env and fill in SNOWFLAKE_ACCOUNT, SNOWFLAKE_USER, and SNOWFLAKE_PRIVATE_KEY_PATH (pointing at rsa_key.p8). Username/password auth is supported as a fallback for local/dev use — see .env.example.

3. Run it standalone (sanity check)

snowflake-cost-mcp

It will sit waiting on stdio — that's expected; it's meant to be launched by an MCP client, not run interactively.

4. Wire it into Claude Desktop / Claude Code

{
  "mcpServers": {
    "snowflake-cost": {
      "command": "snowflake-cost-mcp",
      "env": {
        "SNOWFLAKE_ACCOUNT": "your_account_identifier",
        "SNOWFLAKE_USER": "your_service_user",
        "SNOWFLAKE_PRIVATE_KEY_PATH": "/absolute/path/to/rsa_key.p8",
        "SNOWFLAKE_ROLE": "MCP_COST_MONITOR"
      }
    }
  }
}

Security model (defense in depth)

  1. Every built-in tool runs a hardcoded, parameterized SQL template — no string-built SQL from user input, ever.

  2. run_readonly_query (the only tool that accepts free-form SQL) is off by default and, when enabled, is passed through a guard that rejects anything except a plain SELECT / WITH ... SELECT.

  3. The Snowflake role itself should be read-only (see Prerequisites) — that's the boundary that actually matters if there's ever a bug in this server.

Development

pip install -e ".[dev]"
pytest -q
ruff check src tests

Tests run entirely against a mocked Snowflake connection — no live account needed to develop or run CI.

Roadmap

  • Validate end-to-end against a real Snowflake trial account

  • Publish to the public MCP registry

  • Add a storage-cost tool (database/table storage spend)

  • Optional streamable-HTTP transport for a hosted/enterprise mode

License

MIT — see LICENSE.

Available Tools

6 tools
find_expensive_queriesA

Find the slowest / most expensive successful queries in the lookback window, ranked by elapsed time. Each result includes a truncated query text preview, warehouse, user, elapsed seconds, and GB scanned.

Args: lookback_days: How many days back to look (default from server config). limit: Max number of queries to return (default from server config, typically 50).

Inputs: limit, lookback_days. Returns: result

get_query_detailA

Get full detail for a single query by its Snowflake QUERY_ID, including warehouse size, database/schema, elapsed time, bytes scanned, rows produced, and any error message.

Args: query_id: The Snowflake QUERY_ID (as shown in QUERY_HISTORY or the Snowsight UI).

Inputs: query_id (required). Returns: result

get_warehouse_credit_usageA

Total Snowflake credits consumed per warehouse over the lookback window, split into compute vs. cloud services credits. Use this to see where spend is concentrated before drilling into individual warehouses or queries.

Args: lookback_days: How many days back to look (default from server config, typically 7).

Inputs: lookback_days. Returns: result

get_warehouse_right_sizing_recommendationsA

Heuristic right-sizing recommendations per warehouse, combining credit usage with query queueing behavior:

  • HIGH credits + very low query count -> likely oversized or left running idle; check auto-suspend and whether it's needed at all.

  • Meaningful average queued-overload time -> likely undersized or under-provisioned for concurrency; consider a larger size or a multi-cluster warehouse.

  • Otherwise -> no strong signal either way.

This is a heuristic starting point for investigation, not a guaranteed cost-saving recommendation -- always sanity-check against actual workload requirements before resizing a production warehouse.

Args: lookback_days: How many days back to look (default from server config).

Inputs: lookback_days. Returns: result

list_warehousesA

List all warehouses visible to the connected role, with size, auto-suspend, and auto-resume settings, and current running/queued query counts.

Inputs: no named parameters. Returns: result

run_readonly_queryA

Run an arbitrary read-only SELECT query against Snowflake, for cost or performance investigation beyond the built-in tools. Disabled by default -- must be explicitly enabled via SNOWFLAKE_MCP_ALLOW_ARBITRARY_QUERIES=true in the server environment. Only SELECT / WITH...SELECT statements are accepted; the connected Snowflake role should also be read-only as the primary security boundary.

Args: sql: A single read-only SELECT statement.

Inputs: sql (required). Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 6 tools

    Disambiguation5/5

    Each tool targets a distinct aspect of Snowflake cost and performance: queries (expensive vs detail), warehouses (credit usage, sizing recommendations, listing), and a fallback for arbitrary queries. No overlap in purpose.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern using snake_case (find_expensive_queries, get_query_detail, list_warehouses, etc.). Predictable and readable.

    Tool Count5/5

    With 6 tools, the surface is well-scoped for Snowflake cost management—covering query and warehouse analysis without bloat. Each tool earns its place.

    Completeness4/5

    Covers core cost investigation (expensive queries, warehouse usage, sizing) and includes a generic run tool for gaps. Missing finer breakdowns (e.g., by user/database) but no critical dead ends.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      D
      maintenance
      Enables intelligent data analysis and querying of Snowflake databases through specialized AI agents. Features 20+ tools for data operations, lineage tracing, usage analysis, and performance optimization with multi-agent architecture.
      -
    • F
      license
      Not graded
      quality
      C
      maintenance
      Provides read-only access to Umbrella Cost finops platform, enabling natural language querying of multi-cloud cost data, optimization recommendations, anomaly detection, and budget tracking across AWS, Azure, and GCP.
      -
    • A
      license
      A
      quality
      C
      maintenance
      Provides secure, read-only access to Snowflake data warehouses, enabling AI assistants to explore schemas, write queries, and analyze data with SSO authentication and smart caching.
      6
      37 npm
      5
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables natural language querying and management of Snowflake databases, including SQL execution, schema exploration, and warehouse monitoring.
      MIT