Tune Monte Carlo monitors to reduce alert noise

Analyzes a Monte Carlo data-observability monitor's alert history and recommends concrete configuration changes to reduce alert noise without losing real signal, across metric, custom SQL, validation, and table monitors.

It runs a seven-phase workflow, numbered Phase 0 through Phase 5 with an extra Phase 1.5 in between. Phase 0 validates the monitor UUID passed as an argument. Phase 1 fetches the monitor's alert/incident report (get_monitor_report, up to 50 incidents) and its full configuration (get_monitors) in parallel. Phase 1.5 determines the monitor type from the config and loads a type-specific reference file (references/metric-monitor.md, custom-sql-monitor.md, validation-monitor.md, or table-monitor.md) that documents type-specific fields and tuning guidance. Phase 2 analyzes the report for alert volume/frequency (incidents over 30 and 7 days, firing cadence, whether incidents cluster in bursts), anomaly patterns (which segments or table/metric pairs fire most, whether anomalies are marginal or severe, whether they correlate with known operational events), and the current configuration (schedule interval, audiences, ML vs. explicit thresholds). Phase 3 generates prioritized recommendations, each stating the problem, the exact config field to change, and the trade-off in lost signal - covering sensitivity tuning (step the ML sensitivity down, e.g. HIGH to medium, when anomalies are consistently marginal and assessed as normal variation), schedule/interval adjustments (widen the interval or increase collection_lag for monitors that fire repeatedly on data that resolves within hours or arrives late), snooze/training-period guidance (wait out the model's stabilization period on monitors under 30 days old), and audience/notification routing changes.

{specific config field}: {new value}

Phase 4 presents a structured report - monitor identity/type/schedule, a 30-day alert summary, the root-cause pattern, numbered recommendations each tagged RECOMMENDED or OPTIONAL, what NOT to change, and the predicted outcome of applying the changes - then asks whether to apply any change or explore alert history further. Phase 5 applies changes only on request, always previewing first via each create_or_update_*_monitor tool's dry-run mode (returning rendered MaC YAML for review before a second, dry_run=False call deploys it), always requiring explicit user confirmation, validating the preview YAML against Monte Carlo's published MaC JSON Schema before presenting it, and flagging MaC-managed monitors (offering a handoff to a /manage-mac workflow instead, since API changes get overwritten on the next montecarlo monitors apply).

Use it when a Monte Carlo monitor is generating too many alerts and you need a specific, evidence-based tuning recommendation rather than a blanket sensitivity reduction. It only supports metric, custom SQL, validation, and table monitor types - it stops and tells the user explicitly for any other monitor type.

Input is a monitor UUID. Output is a structured tune report (alert summary, root-cause pattern, prioritized recommendations with exact config changes and trade-offs) and, on request, an applied configuration change with a preview-then-confirm safety gate.

Routes exclusively through this plugin's bundled Monte Carlo MCP server (fully-qualified tool names like mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__get_alerts) - never a separately configured monte-carlo-mcp server that might point at different credentials - and validates config changes against Monte Carlo's published MaC JSON Schema via WebFetch.

Six guidelines govern how recommendations get written: be specific with exact config changes rather than generic advice like "reduce sensitivity"; prefer surgical changes such as a targeted WHERE condition over a blunt sensitivity reduction; preserve signal by always explaining what genuine anomalies would still be caught after tuning; cite evidence by referencing specific incident dates, segment values, and counts from the report; degrade gracefully by noting limited context and reasoning from alert patterns alone if troubleshooting runs are missing; and add a yaml-language-server schema directive when saving MaC YAML to a file.

Data reliability engineers and analytics teams managing Monte Carlo monitors who need noisy alerts diagnosed and tuned with exact, evidence-backed configuration changes rather than trial-and-error sensitivity adjustments.