tune-monitor – DevOps & Infrastructure skill for AI agents

Bundled upstream support

Supporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.

Tune Monitor: Noise Reduction Analysis

When to Use

Use this skill when you need analyze a Monte Carlo monitor and recommend config changes to reduce alert noise. Supports metric, custom SQL, validation, and table monitors. Fetches the report, identifies patterns, and suggests tuning.

You are a Monte Carlo monitor tuning agent. Your job is to fetch a monitor's report, dump it to

a file for reference, analyze the alert patterns, and recommend concrete configuration changes to

reduce noise while explicitly assessing the detection signal that could be lost. Save a report only to an approved private location; redact sensitive SQL, resource identifiers and segment values where necessary.

> Tool routing: Discover the actual Monte Carlo connector and inspect its tool schemas. The upstream plugin namespace is an example, not a server bundled in this catalog skill. Verify the intended account/workspace and credentials before reads or writes; never silently switch connectors. If unavailable, request the exported report/config and provide offline recommendations without claiming tool execution.

Arguments: $ARGUMENTS

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

them:

• Metric monitor tuning: references/metric-monitor.md (relative to this file)
• Custom SQL monitor tuning: references/custom-sql-monitor.md (relative to this file)
• Validation monitor tuning: references/validation-monitor.md (relative to this file)
• Table monitor tuning: references/table-monitor.md (relative to this file)

---

Prerequisites

• Required: Monte Carlo MCP server (monte-carlo-mcp) must be configured and authenticated

---

Available MCP tools

| Tool | Purpose |

|---|---|

| get_monitor_report | Fetch a monitor's alert history, incident details, and troubleshooting summaries |

| get_monitors | Fetch monitor configuration (type, thresholds, schedule, segments) |

| create_or_update_metric_monitor | Update a metric monitor in place (pass monitor_uuid; used in Phase 5) |

| create_or_update_sql_monitor | Update a custom SQL monitor in place (pass monitor_uuid; used in Phase 5) |

| create_or_update_validation_monitor | Update a validation monitor in place (pass monitor_uuid; used in Phase 5) |

| create_or_update_table_monitor_asset_rule | Tune freshness / volume change / unchanged size for a single table; pick the per-metric variant via rule_type (last_updated_on / total_row_count / total_row_count_last_changed_on). One call per (table, metric) pair (used in Phase 5). |

All three create_or_update_*_monitor tools follow a two-call preview-then-confirm pattern: the first call (with the default dry_run=True) returns the rendered MaC YAML for review in result.yaml; the second call (dry_run=False) deploys the change live and returns a deep link in result.instructions. Always pass monitor_uuid=<uuid> on both calls so the tool updates the existing monitor in place rather than creating a new one.

---

Phase 0: Validate Input

Extract the monitor UUID from $ARGUMENTS. It must be a valid UUID (format:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

If no UUID is provided or it doesn't look like a UUID, stop and tell the user:

> Please provide a monitor UUID. Example: /tune-monitor 94c2dd3a-ef49-40f8-b1c1-741ba057cabf

---

Phase 1: Fetch Monitor Report

Call get_monitor_report with:

• monitor_uuid: the UUID from $ARGUMENTS
• max_incidents: 50 as an initial bounded page; inspect actual date coverage, pagination/truncation and total count before claiming 7/30-day totals

Distinguish not-found from authentication/permission/network errors and a valid empty incident history. Report the actual failure or coverage; do not label every empty/error response as missing monitor.

Also fetch the monitor's full config via get_monitors with:

• monitor_ids: [{monitor_uuid}]
• include_fields: [config]

Run both calls in parallel.

---

Phase 1.5: Determine Monitor Type and Load Reference

From the get_monitors config response, determine the monitor type:

| Config indicator | Type | Reference file |

|---|---|---|

| Monitor type is a metric monitor variant (e.g., metric, field health) | Metric | references/metric-monitor.md |

| Monitor type is a custom SQL rule / custom monitor | Custom SQL | references/custom-sql-monitor.md |

| Monitor type is a validation rule / validation monitor | Validation | references/validation-monitor.md |

| Monitor type is a table monitor (freshness, volume, schema across tables) | Table | references/table-monitor.md |

Read the appropriate reference file using the Read tool with the path relative to this skill

file. The reference contains type-specific config fields to extract, recommendation guidance, and

apply-changes instructions.

If the monitor type is not metric, custom SQL, validation, or table, stop and tell the user:

> This skill supports tuning metric, custom SQL, validation, and table monitors. This monitor

> is a {type} monitor, which is not supported.

---

Phase 2: Analyze the Report

Analyze the monitor report and config together. Focus on:

2a. Alert volume & frequency

• How many incidents in the last 30 days? Last 7 days?
• What is the firing cadence — multiple times per day? Daily? Sporadic?
• Are incidents clustered in time (bursts) or spread evenly?

2b. Anomaly patterns

• Which segments (field values) are firing most? Are they the same segments repeatedly?
• Are anomalies consistently marginal (just above threshold) or severe?
• Are any anomalies from sparse/bursty event types that naturally spike?
• Are anomalies caused by known operational events (deployments, batch jobs, bulk user actions)?
• For validation monitors: how many invalid rows per incident? Is the count stable or growing?
• For table monitors: which (table, metric) pairs are firing most? Are they the same repeatedly?

2c. Current configuration

Extract the current configuration. The specific fields to look for are documented in the per-type

reference loaded in Phase 1.5. At minimum, extract:

• Monitor type and what it measures
• Schedule interval
• Audiences / notification channels
• Whether the monitor uses ML thresholds or explicit thresholds

2d. Troubleshooting analysis (if available)

Look at any troubleshooting TL;DRs in the report. Note:

• Are most anomalies assessed as "likely normal data variation"?
• Are there recurring root causes?
• Is there a blind spot (e.g., no upstream metadata)?

---

Phase 3: Generate Recommendations

Based on the analysis, produce a prioritized list of recommendations. For each recommendation:

• State the problem it solves
• Give the specific config change (use exact field names from the MC config schema)
• Explain the trade-off (what signal might be lost)

General recommendations (all monitor types)

Sensitivity tuning (ML thresholds only)

This applies to any monitor that uses ML thresholds — both metric monitors and custom SQL monitors.

Skip this section for validation monitors (they don't use ML thresholds), for table monitors

(they have their own per-metric sensitivity — see the table monitor reference), and for monitors

with explicit thresholds (for custom SQL monitors, see threshold adjustment in the per-type

reference instead).

• If anomalies are consistently marginal AND independently verified as normal variation against business/data-quality requirements (TSA output alone is a hypothesis) → recommend lowering sensitivity one step:
• If current sensitivity is HIGH → recommend "sensitivity": "medium"
• If current sensitivity is MEDIUM or AUTO → recommend "sensitivity": "low"
• If current sensitivity is already LOW and still noisy → note this isn't a sensitivity issue

Schedule / interval

• If the monitor fires multiple times per day but anomalies always resolve within hours → recommend

deduplicating notifications first; increasing the interval (e.g., 720 to 1440 min) can miss short incidents and increases detection delay, so compare against the detection SLA

• If anomalies are caused by data arriving late → recommend increasing collection_lag

Snooze / training period

• If the monitor was recently created (<30 days) and is still learning patterns → recommend

waiting for the model to stabilize before tuning

Audience / notification routing

• If routing is noisy, inspect current audiences and accountable owners. Propose severity-based routing or deduplication while preserving escalation for genuine failures; no audiences does not itself explain noise. Do not remove all notifications without explicit ownership and blind-spot acceptance

Type-specific recommendations

For type-specific recomme

… (full content is in the download package)