Check data asset health and reliability status
Checks a data asset's health via Monte Carlo observability and outputs a structured freshness, alerts, monitoring, and upstream report.
Why it matters
Users hire this skill to quickly assess whether a data table or asset is healthy, reliable, and properly monitored by checking freshness, active alerts, monitoring coverage, importance metrics, and upstream dependency health in Monte Carlo's observability platform.
Outcomes
What it gets done
Retrieve active alerts and incidents affecting the asset in the last 7 days
Check monitoring coverage and identify configuration gaps for important tables
Analyze upstream data dependencies to identify root causes of staleness
Generate structured health reports with actionable recommendations for remediation
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-monte-carlo-asset-health | bash Overview
Monte Carlo Asset Health Skill
This skill checks a specific data asset's health through Monte Carlo's MCP tools and outputs a fixed-format report: freshness, active alerts, monitoring coverage, importance, and upstream dependency status, with rule-based Healthy/Degraded/Unhealthy classification. Use it when someone asks about a specific table's health, status, or reliability, or during incident triage or change planning. Not for exploring table data, creating monitors, or root-causing a live incident - those are separate skills.
What it does
A Monte Carlo observability skill that checks the health of a single data asset and produces a structured health report covering freshness, active alerts, monitoring coverage, importance, and upstream dependency health. It routes all calls through the plugin's bundled MCP server using fully-qualified tool names (mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__<tool>), explicitly avoiding any separately-configured monte-carlo-mcp server that might point at different credentials. Before making any tool calls it requires reading two reference files - workflows.md for exact tool calls and execution order, and parameters.md for parameter conventions. The report format is a fixed template: a header block (table name, tags, link, warehouse, status, importance score, average reads/writes per day), a metrics table (Last Activity, Alerts, Monitoring, Upstream with color-coded signals), then four always-present sections - Active Alerts (max 5 shown, overflow noted as plain text below the table), Monitors, Upstream Issues, and Recommendations - each with defined empty-state text when there's nothing to report, plus a 1-2 sentence Diagnosis. Status is determined by fixed rules: Unhealthy if any active alert exists (not-acknowledged, acknowledged, or work-in-progress), Degraded if there are no active alerts but zero active monitors on a high-importance asset (importance over 0.8 or flagged key asset), and Healthy if there are no active alerts and at least one active monitor. Each metric row is tied to a specific tool: Last Activity from get_table, Alerts from get_alerts, Monitoring from get_monitors (counting non-paused monitors), and Upstream from get_asset_lineage plus additional checks - the skill explicitly forbids inferring or fabricating any value beyond what those tools return, and only reports upstream lineage, never downstream.
When to use - and when NOT to
Activate it when a user asks how a specific table or asset is doing, checks its status or reliability, or references it during incident triage or change planning. Do not use it for profiling or exploring table data like row counts or column stats - that's the explore-table skill; do not use it to create or suggest monitors - that's monitoring-advisor; and do not use it for active root-cause investigation of a firing alert - that's Workflow 3 of the prevent skill. This skill only reports what the defined tools return in a fixed format, so it's not the right tool when the task calls for exploration, monitor creation, or deep incident diagnosis.
Inputs and outputs
Input is the name or identifier of a specific data table or asset. Output is a structured health report following the fixed template, with the health-check webapp URL always resolved dynamically via get_mc_webapp_url() rather than hardcoded, since it varies by environment.
Integrations
Calls Monte Carlo's MCP tools exclusively through the plugin's bundled server (get_alerts, search, get_table, get_monitors, get_asset_lineage, get_mc_webapp_url), never a separately-configured monte-carlo-mcp server in the same session. Output formatting rules require Unicode emoji characters rather than emoji shortcodes, and bare URLs rather than markdown links, since shortcodes render as raw text in a terminal.
Who it's for
Data engineers and analysts who need a quick, consistently-formatted health check on a specific Monte Carlo-monitored asset - covering freshness, alerts, monitoring coverage, and upstream issues - without exploring the table's data or diagnosing a live incident.
Source README
Monte Carlo Asset Health Skill
This skill checks the health of a data asset using Monte Carlo's observability
platform. It produces a structured health report covering freshness, alerts,
monitoring coverage, importance, and upstream dependency health.
Monte Carlo tool routing (required): Always call Monte Carlo MCP tools through this plugin's
bundled server, whose fully-qualified tool names aremcp__plugin_mc-agent-toolkit_monte-carlo-mcp__<tool>(e.g.mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__get_alerts). Bare tool names used in this skill
(get_alerts,search,get_table, …) refer to that bundled server. If the session also has a
separately-configuredmonte-carlo-mcpserver, do not route to it - it may point at a
different endpoint or credentials.
REQUIRED: Read reference files before executing
You MUST read both reference files using the Read tool before making any MCP
tool calls. These files are the source of truth for tool calls, parameters,
and response interpretation. This file only defines when to activate and how to
format the output.
references/workflows.md(relative to this file) - exact tool calls, phases, and execution orderreferences/parameters.md(relative to this file) - parameter conventions and field details
Do NOT make any MCP tool calls until you have read both files.
When to activate this skill
Activate when the user:
- Asks about health: "how is table X doing?", "check health of X", "is X healthy?"
- Asks about status: "what's the status of X?", "status of orders table"
- Asks to check on a table: "check on X table", "check on X"
- Asks about reliability, freshness, or quality of a specific asset
- References a table in context of incident triage or change planning
When NOT to activate this skill
- Profiling or exploring table data (row counts, column stats, distributions) → use
explore-table - Creating or suggesting monitors → use
monitoring-advisor - Active incident triage (investigating root cause of a firing alert) → use prevent skill Workflow 3
Health report format
CRITICAL: Only report data returned by the tools defined in references/workflows.md.
Do NOT call additional tools, do NOT infer or fabricate metrics. Each row below
specifies exactly which tool provides its value.
All sections (Active Alerts, Monitors, Upstream Issues, Recommendations) must
always appear with their heading. Never omit a section - if there is no data,
show the empty-state text defined below.
Never use emoji shortcodes (like :warning: or :arrow_up:). Use Unicode
emoji characters directly (like ⚠️) or plain text. Shortcodes render as raw text
in the terminal.
Always display URLs as bare URLs, never as markdown links (e.g., [text](https://github.com/monte-carlo-data/mc-agent-toolkit/tree/main/skills/asset-health/url)).
{MC_WEBAPP_URL} appears throughout this template. Every occurrence must be
replaced with the actual value returned by calling get_mc_webapp_url(). Never
hardcode or guess this URL - it varies by environment.
Present results in this structure:
### Health Check: <table_name>
**Tags:** `tag1:value1`, `tag2:value2` (or "None" if no tags)
**Link:** {MC_WEBAPP_URL}/assets/{mcon}
**Warehouse:** snowflake-prod (Snowflake)
**Status: 🟢 Healthy / 🟡 Degraded / 🔴 Unhealthy** | **Importance:** 0.85 (key asset ⭐️)
**Avg Reads/Day:** ~538 | **Avg Writes/Day:** ~12
| Metric | Value | Signal |
|---------------|--------------------------------|--------|
| Last Activity | Apr 6, 2025 | 🟢 Recent |
| Alerts | 2 active | 🔴 Has alerts |
| Monitoring | 3 active monitors | 🟢 Monitored |
| Upstream | 1/3 sources unhealthy | 🔴 Issues |
### Active Alerts
| Date | Type | Priority | Status | Link |
|-------|----------------|----------|------------------|---------------------------------------------------------|
| Apr 8 | Metric anomaly | P3 | Not acknowledged | {MC_WEBAPP_URL}/alerts/{alert_uuid} |
| Apr 7 | Freshness | P2 | Acknowledged | {MC_WEBAPP_URL}/alerts/{alert_uuid} |
If there are more than 5 active alerts, display only 5. Do NOT put the overflow
message inside the table as a row. Instead, put it as plain text on the line
immediately after the table:
There are N more alerts not shown for brevity
If there are zero active alerts, show:
No active alerts in the last 7 days.
### Monitors
| Type | Name | Incidents (7d) | Status |
|-------------|-----------------------------------------|----------------|---------------------|
| TABLE | Orders freshness and schema | 3 | Running hourly |
| METRIC | Revenue row count | 0 | Never executed |
| BULK_METRIC | Warehouse volume check | 21 | ⚠️ 1 table has errors |
If there are zero monitors, show:
No monitors configured for this table.
### Upstream Issues
- raw_orders — FRESHNESS alert: not updated in 8h
- raw_payments — healthy
- dim_customers — healthy
> Want me to check further upstream for **raw_orders**?
If there are no upstream dependencies, show:
No upstream dependencies found.
### Diagnosis
1-2 sentences summarizing what is causing the table to be unhealthy, or
confirming it is healthy. This should naturally lead into the recommendations.
Example (unhealthy):
Upstream table raw_orders has not been updated in 8 hours, which is likely
causing staleness in this table. There are also 2 unacknowledged alerts.
Example (healthy):
Table is healthy — no active alerts, monitored, and all upstream sources
are in good shape.
### Recommendations
- Investigate upstream raw_orders freshness — likely root cause of this table's staleness
- Acknowledge or investigate the 2 active alerts
If there are no recommendations, show:
No recommendations — table looks healthy.
Metric definitions - exact data sources
Each metric row MUST use only the specified data source. Do not add, infer, or
embellish values beyond what the tool returns.
| Metric | Data source | What to show | Signal |
|---|---|---|---|
| Last Activity | get_table → last_activity |
Date of last activity (e.g., "Apr 6, 2025") | 🟢 Recent (within 7 days) / 🟡 Stale (older than 7 days) |
| Alerts | get_alerts → count |
"N active" or "No active alerts" | 🔴 Has alerts / 🟢 No alerts |
| Monitoring | get_monitors → count where is_paused is false |
"N active monitors" or "0 active monitors (M paused)". Include relevant details from monitor fields (incident counts, error counts, types). | 🟢 Monitored (≥1 active) / 🔴 Unmonitored (0 active) |
| Upstream | get_asset_lineage (upstream) + Phase 3 checks |
"N/M sources unhealthy" or "All N sources healthy" | 🔴 Issues (any unhealthy) / 🟢 Healthy (all healthy) |
Importance is shown next to the Status line (not in the metrics table). Source:get_table → importance_score + is_important. Show "X.XX (key asset ⭐️)" if
key asset or importance > 0.8, otherwise just "X.XX".
Avg Reads/Day and Avg Writes/Day are shown below the Status line. Source:get_table → table_stats.avg_reads_per_active_day and table_stats.avg_writes_per_active_day.
Do NOT include downstream data. This skill only queries upstream lineage.
Status determination
- 🔴 Unhealthy: Any active alerts on the asset (from
get_alertswith statuses["NOT_ACKNOWLEDGED", "ACKNOWLEDGED", "WORK_IN_PROGRESS"]- seeparameters.md) - 🟡 Degraded: No active alerts, but 0 active monitors on a high-importance
asset (importance > 0.8 or key asset) - 🟢 Healthy: No active alerts and has at least 1 active monitor
Tags
Display tags from the search tool's properties field. Show as inline badges:key:value. If no tags exist, show "None". Always include the Tags line.
Warehouse
Display the warehouse name and type from the search result. Always include this line.
Recommendations
Only include recommendations derivable from collected data:
- Upstream health issues that may be root causes
- Active alerts that need acknowledgment or investigation
- Do NOT recommend specific monitor types - that is outside this skill's scope
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.