Monte Carlo Root Cause Analysis Skill

This skill helps investigate data incidents — freshness delays, volume anomalies, schema changes, field metric drift, and ETL failures — by guiding the agent through a systematic investigation using Monte Carlo's MCP tools. It combines observability metadata with optional direct data querying to find the root cause.

Reference files live next to this skill file. Use the Read tool (not MCP resources) to access them:

• Investigation playbooks by issue type:

  references/<type>-investigation.md

• Data exploration patterns:

  references/data-exploration.md

• Intake when no incident ID:

  references/intake-no-incident.md

• Common root cause catalog:

  references/common-root-causes.md

When to activate this skill

Activate when the user:

• Mentions a Monte Carlo alert, incident, or anomaly
• Asks "why is this table stale?" or "why did row count drop?"
• Wants to investigate a data quality issue
• Asks about freshness, volume, or schema problems
• Mentions pipeline failures (Airflow, dbt, Databricks)
• Says things like "debug this alert", "investigate this incident", "root cause analysis"

When NOT to activate this skill

Do not activate when the user is:

• Creating monitors (use the monitoring-advisor skill)
• Running impact assessments before code changes (use the prevent skill)
• Looking at storage costs (use the storage-cost-analysis skill)
• Exploring pipeline performance without a specific incident (use the performance-diagnosis skill)

Prerequisites

Required: Monte Carlo MCP server (

integrations.getmontecarlo.com/mcp

Optional but recommended:

• Database MCP server (Snowflake, BigQuery, Redshift, Databricks) — enables direct SQL queries for deeper data investigation. Without this, the skill can still analyze using MC's metadata tools but cannot profile actual data.
• GitHub MCP server — enables searching for recent PRs that may have caused the issue. Without this, the skill falls back to MC's query change detection.

MCP Tools Used

From Monte Carlo MCP server

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

platform

get_etl_jobs

platform

get_github_prs

get_jobs_performance

get_change_timeline

get_current_time

Optional external MCP tools

get_github_prs

Workflow

Step 1: Understand the problem (intake)

If the user provides an alert or incident ID:

1. Call

   get_alerts

   with the alert ID to fetch details.
2. Identify: affected table(s), issue type (freshness, volume, schema, field metric), when it started.
3. Proceed to Step 2.

If the user describes a problem WITHOUT an incident ID: Read

references/intake-no-incident.md

1. Ask clarifying questions: what table? what looks wrong? when did it start?
2. Search for the table:

   search(query="table_name")

3. Search for related alerts:

   get_alerts

   with a recent time range
4. Check table health:

   get_table_freshness

   ,

   get_table_size_history

5. Narrow down the issue type and proceed to Step 2.

Step 2: Map the blast radius

1. Call

   get_asset_lineage(mcons=[table_mcon], direction="UPSTREAM")

   — what feeds this table?
2. Call

   get_asset_lineage(mcons=[table_mcon], direction="DOWNSTREAM")

   — what does this table feed?
3. If the issue involves specific fields, call

   get_field_lineage

   to trace which upstream fields feed the affected columns.

Report to the user: "This table is fed by X upstream sources and feeds Y downstream consumers. Here's what could be impacted."

Ask for direction: Before diving deeper, ask the user what they'd like to investigate first. They may already have a hunch ("I think it's the Airflow job" or "check if someone changed the SQL"). Follow their lead — don't run all investigation paths blindly. If they have no preference, proceed with the most likely path based on the issue type.

Step 3: Investigate based on issue type

Read the appropriate reference file and follow its investigation playbook:

references/freshness-investigation.md

references/volume-investigation.md

references/schema-investigation.md

references/etl-failure-investigation.md

references/query-change-investigation.md

references/field-anomaly-investigation.md

Step 4: Check for upstream causes

Data issues often originate upstream. Walk the lineage chain:

1. For each direct upstream table from Step 2:
   • Check freshness:

     get_table_freshness

     — is the upstream table also stale?
   • Check size:

     get_table_size_history

     — did the upstream table's volume change?
   • Check ETL status:

     get_etl_issues

     with the relevant

     platform

2. Use

   get_field_lineage

   to trace the specific field that has bad data back to its source.
3. Check what upstream field values correlate with the anomaly (if DB connector is available — see Step 5).

Step 5: Profile data (if database MCP is available)

If the user has a database MCP server connected (Snowflake, BigQuery, Redshift, Databricks, etc.), read

references/data-exploration.md

• Sample rows around the incident time
• Null rate and distribution checks
• Value correlation with upstream tables
• Before/after comparisons

If no database MCP is available: Tell the user: "I can't query the warehouse directly — for deeper data investigation, connect a database MCP server. I can still analyze using Monte Carlo's metadata and the tools available." Continue the investigation with MC tools only.

Step 6: Check for code changes

Call

get_github_prs

If the account has no GitHub integration (tool returns empty), or the user has a local GitHub MCP server they prefer, use that instead.

Also call

get_query_changes

get_change_timeline

Step 7: Synthesize and present

Read

references/common-root-causes.md

1. Root cause — what happened and when, with evidence from tools
2. Evidence chain — which tools confirmed each piece of the story
3. Impact — what downstream tables/consumers are affected (from Step 2)
4. Recommended fix — specific action to resolve the issue
5. Prevention — suggest monitoring to catch this earlier next time

Important rules

• Never fabricate data. Only cite numbers and facts returned by tools. If a tool returned no data, say so.
• Follow the evidence. If upstream lineage shows no issues, the problem is likely in the table's own ETL. Don't chase phantom upstream causes.
• Check the timeline. The most common pattern is: "X changed at time T, and the anomaly started at time T+1." Use

  get_change_timeline

  for this.
• Be specific about what you can't check. If no DB connector is available, explain what additional investigation would be possible with one.
• Never expose MCONs, UUIDs, or internal identifiers to the user. Use human-readable table names.
• Cross-platform awareness. ETL issues can come from Airflow, dbt, or Databricks. Check all platforms that are relevant.