Tune Monte Carlo monitors to reduce alert noise

Acts as a Monte Carlo monitor tuning agent: it fetches a monitor's alert report, analyzes the firing patterns, and recommends concrete configuration changes that reduce alert noise without sacrificing real signal. It supports metric monitors, custom SQL monitors, validation monitors, and table monitors, each of which loads its own reference file (references/metric-monitor.md, references/custom-sql-monitor.md, references/validation-monitor.md, references/table-monitor.md) for type-specific fields, recommendation guidance, and apply-changes instructions. All Monte Carlo MCP calls route through the bundled plugin server under 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 a different endpoint or credentials, and the Monte Carlo MCP server must be configured and authenticated before use.

The workflow runs in five phases. Phase 0 validates that the input argument is a UUID in the standard xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx form, stopping to ask for one if missing or malformed. Phase 1 fetches the monitor's report via get_monitor_report with max_incidents: 50 and its config via get_monitors with include_fields: ["config"], run in parallel, stopping if the monitor isn't found. Phase 1.5 determines the monitor type from the config response and reads the matching reference file with the Read tool, stopping if the type is none of the four supported.

Phase 2 analyzes the report and config together across four dimensions: alert volume and frequency (incident counts over 30 and 7 days, firing cadence, whether incidents cluster in bursts or spread evenly); anomaly patterns (which segments or, for table monitors, which table/metric pairs fire most, whether anomalies are marginal or severe, whether they trace to known operational events like deployments or batch jobs, and for validation monitors whether invalid-row counts are stable or growing); current configuration (monitor type, schedule interval, audiences, and whether it uses ML thresholds or explicit thresholds); and troubleshooting analysis where available (whether anomalies are mostly assessed as normal variation, recurring root causes, or blind spots like missing upstream metadata).

Phase 3 turns that analysis into a prioritized recommendation list, each stating the problem it solves, the specific config change using exact field names from the Monte Carlo config schema, and the trade-off in lost signal. General recommendations apply across monitor types: sensitivity tuning for monitors using ML thresholds (stepping HIGH to medium or MEDIUM/AUTO to low when anomalies are consistently marginal and assessed as normal, skipped for validation monitors, table monitors with their own per-metric sensitivity, and monitors with explicit thresholds); schedule and interval changes (widening the interval when anomalies always resolve within hours, or increasing collection_lag when data arrives late); snooze/training-period guidance for monitors under 30 days old still learning patterns; and audience/notification routing changes for monitors generating noise with no audiences or that should have notifications removed entirely. Type-specific recommendations, such as WHERE conditions, segment exclusion, aggregation changes, threshold adjustment, SQL modifications, or per-table-metric sensitivity, follow the loaded reference file.

Phase 4 presents a fixed-format structured report as the primary output: monitor identity and type, what it monitors, current sensitivity, schedule, a 30-day alert summary with firing frequency and the noisiest segments or table/metric pairs, a root-cause pattern summary, a prioritized recommendations section each with problem/change/trade-off, a "what NOT to change" section to avoid over-tuning correct configuration, and a predicted outcome if the changes are made, closing by asking whether to apply any changes or explore the alert history further.

Phase 5 applies changes only on request, using the tool and constraints specified in the per-type reference: create_or_update_metric_monitor, create_or_update_sql_monitor, and create_or_update_validation_monitor for their respective types, and create_or_update_table_monitor_asset_rule (picking the rule_type of last_updated_on, total_row_count, or total_row_count_last_changed_on, one call per table/metric pair) for table monitors. All three create_or_update_*_monitor tools use a two-call preview-then-confirm pattern, a default dry_run=True call returning rendered MaC YAML in result.yaml for review, then dry_run=False to deploy live and return a deep link in result.instructions, always passing monitor_uuid on both calls so the existing monitor is updated in place rather than a new one created. Before presenting preview YAML, it fetches the published MaC JSON Schema from https://clidocs.getmontecarlo.com/mac/schema.json and validates the YAML against it, flagging and correcting any field absent from the schema, noting that the schema checks only field names, types, and enum values while cross-field semantic constraints are enforced by the backend at apply time. If get_monitors returns a mac_name, or the user says the monitor is MaC-managed, it flags that API changes will be overwritten on the next montecarlo monitors apply and offers to hand off to /manage-mac instead so the YAML file stays the source of truth. If the user asks to save the YAML to a file, it adds # yaml-language-server: $schema=https://clidocs.getmontecarlo.com/mac/schema.json as the file's first line.

Guidelines throughout: prefer specific config changes over generic advice, prefer surgical targeted changes like a WHERE condition over a blunt sensitivity reduction, always explain what genuine anomalies would still be caught after tuning, cite specific incident dates, segment values, and counts from the report as evidence, and degrade gracefully by reasoning from alert patterns alone when troubleshooting runs are missing.

Use it to analyze a Monte Carlo metric, custom SQL, validation, or table monitor and recommend config changes that reduce alert noise while preserving real signal. Skip it for monitor types outside those four, and always preview and get explicit user confirmation before applying any change to a live monitor.

Input is a Monte Carlo monitor UUID. Output is a structured Monitor Tune Report (alert summary, root cause, prioritized recommendations, what not to change, predicted outcome) and, on request, an applied config change delivered via a preview-then-confirm tool call.

Calls the Monte Carlo MCP server through the bundled mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__ tools (get_monitor_report, get_monitors, the create_or_update_*_monitor family), validates preview YAML against the published MaC JSON Schema via WebFetch, and can hand off to /manage-mac for YAML-managed monitors.

Data and analytics engineers who own Monte Carlo monitors and want a systematic, evidence-based way to cut alert noise without losing genuine anomaly detection.