Investigate data incidents and find root causes

Monte Carlo Root Cause Analysis guides an agent through a systematic investigation of data incidents: freshness delays, volume anomalies, schema changes, field metric drift and ETL failures. It combines Monte Carlo's observability metadata with optional direct data querying to find the root cause. It is a community skill from the monte-carlo-data/mc-agent-toolkit under the Apache-2.0 license. All Monte Carlo tools must be called through the plugin's bundled MCP server, not through a separately configured monte-carlo-mcp server that may point at different credentials.

Requirements: the Monte Carlo MCP server must be configured and authenticated. Optional but recommended are a database MCP server (Snowflake, BigQuery, Redshift or Databricks) for direct SQL profiling and a GitHub MCP server for finding recent pull requests; without them the skill falls back to metadata analysis and Monte Carlo's query change detection.

The workflow has seven steps, with a Step 1.5:

1. Intake. With an alert or incident ID, fetch it with get_alerts and identify the affected tables, issue type and start time. Without an ID, ask which table, what looks wrong and when it started, search for the table and related alerts, and check freshness and size history to narrow the issue type.
   1.5. Troubleshooting Agent (TSA). When intake yields an incident UUID, start Monte Carlo's Troubleshooting Agent asynchronously before continuing, since it runs the same analysis as the Monte Carlo UI and works in parallel with the manual investigation:

run_troubleshooting_agent(incident_id="<uuid>", async_mode=True)

The call is idempotent, returning existing results unless force_rerun=True, which should be used only if the user asks for a fresh analysis because each fresh run consumes credits. TSA typically finishes in 4 to 8 minutes. Skip it when there is no incident UUID, when the user wants a single fact such as whether a table is stale right now, or when the user opts out with phrases like "skip TSA" or "manual only". If it fails, continue manually without re-running.
2. Map the blast radius. Get upstream and downstream lineage, and field lineage when specific columns are affected, then report how many sources feed the table and how many consumers it feeds. Ask the user where to start, since they may already suspect an Airflow job or a SQL change.
3. Investigate by issue type, using reference playbooks: freshness (table not updating on schedule), volume (unexpected row count changes), schema (columns added, removed or retyped), ETL failure (Airflow, dbt or Databricks), query change (SQL modifications) and field anomaly (null rate, mean and similar drift).
4. Check upstream causes by walking the lineage chain: freshness and size history of each upstream table, ETL status per platform, and field lineage back to the source column. Poll TSA once here, about 30 seconds after starting it.
5. Profile data if a database MCP is available, with samples around the incident time, null-rate and distribution checks, correlation with upstream tables and before and after comparisons. If not, say so and continue with Monte Carlo tools only.
6. Check for code changes with recent pull requests from the account's Monte Carlo GitHub integration (or a local GitHub MCP), plus query change detection and a unified change timeline that combines query modifications, volume shifts and ETL failures.
7. Synthesize and present the root cause with timing and evidence, the evidence chain by tool, downstream impact, a recommended fix and prevention suggestions such as monitoring. A second TSA poll comes 60 to 90 seconds after the first; if TSA is still running, present manual findings and offer to fold in TSA results later. When TSA agrees, lead with the unified cause; when it contradicts the manual work, show both and ask which thread to pull; when its output is low-signal, cite it as a corroborating null result; and if it failed, mention that briefly.

Activate when the user mentions a Monte Carlo alert, incident or anomaly, asks why a table is stale or why a row count dropped, wants to investigate a data quality issue, asks about freshness, volume or schema problems, mentions failures in Airflow, dbt or Databricks pipelines, or says "debug this alert", "investigate this incident" or "root cause analysis".

Do not use it to create monitors (use the monitoring-advisor skill), run impact assessments before code changes (the prevent skill), look at storage costs (storage-cost-analysis) or explore pipeline performance without a specific incident (performance-diagnosis). It should be used only when the task matches its upstream context, and commands, credentials and external service behavior must be verified before applying changes.

Inputs are an incident or alert ID, or a described problem. Outputs are a structured root cause report. Rules: never fabricate data, and cite only what tools returned; follow the evidence and do not chase phantom upstream causes; check the timeline, since the common pattern is that something changed at time T and the anomaly began just after; state what cannot be checked without a database connector; never expose internal identifiers such as MCONs or UUIDs, and use readable table names; and consider all relevant ETL platforms.

Monte Carlo tools include get_alerts, search, get_table, get_asset_lineage, get_field_lineage, get_table_freshness, get_table_size_history, get_queries_for_table, get_query_changes, get_query_rca, get_etl_issues, get_etl_jobs, get_github_prs, get_jobs_performance, get_change_timeline, get_current_time, alert_assessment (an optional roughly 2-minute triage returning HIGH, MEDIUM or LOW confidence and impact), run_troubleshooting_agent and get_troubleshooting_agent_results. Both alert_assessment and run_troubleshooting_agent consume Monte Carlo credits. Optional external MCP servers cover databases and GitHub.

It suits data engineers and analytics engineers on Monte Carlo who must diagnose data incidents quickly and want a repeatable, evidence-based process.