Find stale warehouse tables to cut storage costs

A Monte Carlo skill that analyzes a data warehouse for stale tables that can be removed to reduce storage costs, delegating classification, safety scoring, and formatting entirely to the analyze_storage_costs MCP tool rather than reasoning about it itself. That tool fetches candidates, classifies them into six waste patterns (Unread, Write-only, Dead-end, Static waste, Zombie, Other stale) and four table categories (Temporary/Staging, Archive/Snapshot, Production, Other), computes safety tiers, and returns pre-formatted output as two regions: a PRESENT_AS_IS block (condensed summary, Top-N table, drill-down prompt) that the skill copies verbatim with no reformatting, and a CATEGORY_DETAILS block with per-category tables that stay hidden until the user asks about a specific category. Critically, once analyze_storage_costs succeeds, the skill calls no other tool to cross-check or search - the result is treated as the final answer, and markdown-linked MCONs in the tables must be preserved exactly, never flattened to bare strings. Category drill-down requests are matched by keyword (temporary/staging/tmp/stg, archive/snapshot/backup/old, uncategorized/other/unknown, production/prod/critical/important) and answered from the already-returned data without re-invoking the tool. A separate lineage-check path uses get_asset_lineage with downstream direction when the user asks whether a specific table is safe to remove: no tracked relationships suggests the consumers are likely BI dashboards rather than other tables (still worth verifying with dashboard owners), stale downstream tables support removing both, and active downstream tables get flagged as risky. Each result row's Usage & Risk cell combines an activity value (no reads; days-since-read plus zero reads; or recent reads with total count and distinct users) with risk flags appended in fixed order when they fire - criticality level, consumer count (including non-table BI assets that the lineage tool itself can't see, which is called out explicitly as a source of undercounting), a Databricks-computed importance-score threshold, and active monitoring status.

Use it when someone asks about storage costs, waste, or cleanup opportunities, wants to find unused or stale tables, or asks which tables can be dropped. Do NOT use it for querying or exploring table contents generally, creating or modifying monitors (the monitoring-advisor skill), investigating data quality incidents (the prevent skill), or pipeline performance and query cost questions (the performance-diagnosis skill).

Input is a warehouse (named, or auto-selected/prompted-for if only one or several supported warehouses exist) among Snowflake, BigQuery, Redshift, or Databricks. Output is a verbatim-presented cost-waste summary and Top-N table, expandable per-category tables on request, and lineage-informed removal guidance - always a recommendation, never an executed DROP TABLE or other destructive action.

Runs through Monte Carlo's bundled MCP server, primarily the single analyze_storage_costs tool for the full analysis pipeline and get_asset_lineage for follow-up lineage checks only - both routed through fully-qualified plugin tool names, never a separately-configured monte-carlo-mcp server.

Data platform teams looking to cut warehouse storage spend who want a pre-scored, safety-tiered list of candidate tables to drop - covering temporary, archived, and zombie tables - without manually cross-referencing read activity, lineage, and monitoring status themselves.