Check data asset health and reliability status

Checks the health of a specific data asset using Monte Carlo's observability platform, producing a structured health report covering freshness, alerts, monitoring coverage, importance, and upstream dependency health. All Monte Carlo MCP tool calls route through the plugin's bundled server (fully-qualified names like mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__get_alerts), never a separately-configured monte-carlo-mcp server that might point at a different endpoint or credentials. Before making any MCP tool call, it requires reading two reference files as the source of truth for exact tool calls, parameters and response interpretation: references/workflows.md for the phases and execution order, and references/parameters.md for parameter conventions and field details.

It activates when the user asks how a table is doing, checks its status, checks on a specific table, asks about its reliability, freshness or quality, or references a table for incident triage or change planning. It does not activate for profiling or exploring table data like row counts or distributions (that's the explore-table skill), for creating or suggesting monitors (the monitoring-advisor skill), or for active incident root-cause investigation of a firing alert (prevent skill Workflow 3).

The health report only shows data returned by the tools named in references/workflows.md, never inferred or fabricated metrics, and always displays all four sections (Active Alerts, Monitors, Upstream Issues, Recommendations) with their heading, showing a defined empty-state text when a section has no data rather than omitting it. It never uses emoji shortcodes, only Unicode emoji characters or plain text, always shows URLs as bare URLs rather than markdown links, and replaces every occurrence of {MC_WEBAPP_URL} in the template with the actual value from calling get_mc_webapp_url() rather than hardcoding or guessing it, since it varies by environment.

The report opens with the table name, its tags as inline key:value badges (or "None"), a link built from the webapp URL and asset identifier, the warehouse name and type, an overall status (Healthy, Degraded, or Unhealthy) plus an importance score, and average reads/writes per day, followed by a summary metrics table for Last Activity, Alerts, Monitoring and Upstream, each with its own value and a green/yellow/red signal. Each metric has an exact required data source: Last Activity comes from get_table's last_activity field (green if within 7 days, yellow if older); Alerts comes from get_alerts's count (red if any active, green if none); Monitoring comes from get_monitors's count of monitors where is_paused is false, including relevant incident and error-count details (green if at least one active, red if zero); and Upstream comes from get_asset_lineage's upstream results combined with health checks on those sources (red if any are unhealthy, green if all are healthy). Importance is shown next to the status line, sourced from get_table's importance_score and is_important fields, flagged as a key asset when importance exceeds 0.8. Average reads and writes per day are sourced from get_table's table_stats.avg_reads_per_active_day and table_stats.avg_writes_per_active_day. The skill only queries upstream lineage and never includes downstream data.

Active Alerts lists up to 5 alerts by date, type, priority, status and link, with any overflow beyond 5 stated as plain text below the table (never as a table row) and a defined empty-state line when there are zero. Monitors lists each monitor's type, name, incident count over 7 days, and status, with a defined empty-state line when none are configured. Upstream Issues lists each upstream source's freshness status in plain bullet form, offering to check further upstream on an unhealthy source, with a defined empty-state line when there are no upstream dependencies. A Diagnosis section gives one to two sentences summarizing what is causing the table to be unhealthy, or confirming it is healthy, feeding naturally into a Recommendations section that only includes items derivable from the collected data, such as investigating an upstream freshness issue or acknowledging active alerts, explicitly never recommending specific monitor types since that's outside this skill's scope, with a defined empty-state line when there are no recommendations.

Overall status is determined by fixed rules: Unhealthy if there are any active alerts (from get_alerts with statuses NOT_ACKNOWLEDGED, ACKNOWLEDGED, or WORK_IN_PROGRESS); Degraded if there are no active alerts but zero active monitors on a high-importance asset (importance above 0.8 or flagged as a key asset); and Healthy if there are no active alerts and at least one active monitor.

Use it when the user asks how a table or asset is doing, checks its status or health, or references it for incident triage or change planning. Skip it for profiling or exploring table data (use explore-table), for creating or suggesting monitors (use monitoring-advisor), or for active root-cause investigation of a firing alert (use the prevent skill's Workflow 3).

Input is the name of a specific data asset or table to check. Output is a structured health report with an overall status, a summary metrics table, active alerts, configured monitors, upstream dependency issues, a diagnosis, and data-derived recommendations.

Calls Monte Carlo MCP tools (get_table, get_alerts, get_monitors, get_asset_lineage, search, get_mc_webapp_url) exclusively through the plugin's bundled mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__ server, and requires reading its own references/workflows.md and references/parameters.md before any tool call.

Data teams who need a quick, tool-sourced health check on a specific table or asset, its alerts, monitoring coverage, importance, and upstream dependency health, before triaging an incident or planning a change.