Investigate data incidents and find root causes

A skill for investigating data incidents - freshness delays, volume anomalies, schema changes, field metric drift, and ETL failures - using Monte Carlo's MCP tools, combining observability metadata with optional direct data querying to find the root cause. All Monte Carlo MCP calls must route through this plugin's bundled server (mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__<tool>), never a separately-configured monte-carlo-mcp server that might point at different credentials. It requires the Monte Carlo MCP server to be configured and authenticated, and optionally a database MCP server (Snowflake, BigQuery, Redshift, Databricks) for direct SQL profiling and a GitHub MCP server for searching recent PRs. It exposes tools including 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, alert_assessment (a roughly two-minute triage returning HIGH/MEDIUM/LOW confidence and impact), and run_troubleshooting_agent / get_troubleshooting_agent_results for the async Troubleshooting Agent (TSA) - noting that alert_assessment and run_troubleshooting_agent consume billable Monte Carlo credits, so force_rerun=True should only be passed when the user explicitly asks for a fresh analysis. The workflow runs seven steps. Step 1 intake identifies the affected table, issue type, and start time from an incident ID via get_alerts, or, without an incident ID, asks clarifying questions and searches via search, get_alerts, get_table_freshness, and get_table_size_history. Step 1.5 auto-invokes TSA in async parallel mode whenever an incident UUID is available - typically completing in four to eight minutes - unless there is no UUID, the user wants a single narrow fact (like "is this table stale right now?"), or the user explicitly opts out ("skip TSA", "manual only"); TSA is idempotent by default and returns existing results rather than re-running. Step 2 maps the blast radius via get_asset_lineage in both UPSTREAM and DOWNSTREAM directions and get_field_lineage for affected columns, then asks the user which direction to investigate first rather than running every path blindly. Step 3 follows the matching investigation playbook by issue type: freshness, volume, schema, ETL failure (Airflow/dbt/Databricks), query change, or field-anomaly investigation, each in its own references/<type>-investigation.md file. Step 4 checks upstream causes by walking the lineage chain, checking each upstream table's freshness and size history for the same anomaly.

Activate it when a user mentions a Monte Carlo alert, incident, or anomaly, asks why a table is stale or why row count dropped, wants to investigate a data quality issue, or mentions pipeline failures in Airflow, dbt, or Databricks. Do not activate it for creating monitors (use the monitoring-advisor skill instead), running pre-change impact assessments (use the prevent skill), storage cost analysis (use the storage-cost-analysis skill), or general pipeline performance exploration without a specific incident (use the performance-diagnosis skill).

Input is a Monte Carlo incident/alert ID, or a user description of a data problem (which table, what looks wrong, when it started) when no ID is available. Output is a root-cause diagnosis grounded in lineage, freshness/volume history, query change detection, and ETL job status - optionally corroborated by an async Troubleshooting Agent run with a HIGH/MEDIUM/LOW confidence and impact assessment.

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

Integrates with the Monte Carlo MCP server (required), and optionally a database MCP server (Snowflake, BigQuery, Redshift, Databricks) for direct SQL profiling and a GitHub MCP server for recent PR search as an alternative to Monte Carlo's own get_github_prs. Reads reference playbooks under references/ by issue type, plus references/data-exploration.md, references/intake-no-incident.md, and references/common-root-causes.md.

Data engineers and analysts investigating a specific Monte Carlo-flagged data incident - freshness delays, volume anomalies, schema changes, field drift, or ETL failures - who need a systematic, lineage-aware root-cause investigation rather than ad hoc metadata browsing.