Repository navigation
Lite's MCP reports 4 alert groups to Darling's 48, and cannot write any of them #2394
Description
Surfaced by the review on #2392, which correctly declined to fix it there — it is much larger than the file-growth knobs that PR was about, and #2392 does not make it worse.
Lite's McpAlertTools.GetAlertSettings reports four groups:
cpu blocking deadlocks smtp
Darling's update_alert_settings alone dispatches on 48 top-level and nested keys, and its get_alert_settings reports the matching read shape. Lite has no update_alert_settings tool at all.
So on Lite, an MCP client cannot read whether tempdb-space, low-disk, PVS, long-running-query, long-running-job, failed-job, database-state, file-growth, analysis, connection, or AG alerting is even on — and cannot change any setting, including the four it can read.
Two things make this worth fixing rather than accepting:
The engine is shared. PerformanceMonitor.Alerting evaluates the same alerts on both SKUs against IAlertEngineSettings, and AppAlertEngineSettings already projects every one of Lite's App.Alert* statics onto that interface. The gap is purely the MCP surface — nothing about Lite's alerting is actually narrower.
And #2391 was this same shape at smaller scale: a knob wired end to end with no way to reach it, where the workaround was hand-editing the config. Here the workaround is hand-editing settings.json, which is worse on Lite than on Darling because there is no store-side plane to fall back to.
There is one real design question to settle first, which is likely why this never happened. Darling's tools write to config_alert_settings, and the service picks the change up through StoreConfigProvider.ApplyToConfig — a live reload with no restart. Lite has no equivalent: its settings live in App.Alert* statics that the Settings window writes to settings.json, and an MCP write would have to mutate those statics AND persist them AND stay coherent with a Settings window that may be open with stale values loaded. SaveAlertSettings reads its controls, not the statics, so it would happily overwrite an MCP-applied change on the next Save.
Reasonable scopes, smallest first:
- Read-only parity. Extend
get_alert_settingsto report every group Darling reports. No coherency problem at all, and it is most of the practical value — an agent triaging a Lite instance can at least see the configuration. - Read-only parity plus a narrow update. Add
update_alert_settingsbut have it reject while the Settings window is open, sidestepping the stale-overwrite case rather than solving it. - Full parity. Give Lite a change-notification seam so the Settings window reloads on an external write. Correct, and clearly the largest.
Note McpAlertSettingsKeyTests pins the wire key names Lite already emits, so a read-only expansion needs those assertions extended, not rewritten.
Activity
Remove files that belong to other branches from this one
erikdarlingdata commentedon Aug 21, 2026
Fixed on
devby #2410. Lite'sget_alert_settingsnow reports 13 further groups —poison_wait,long_running_query,tempdb_space,low_disk,pvs,file_growth,long_running_job,failed_job,database_state,cooldown_minutes,excluded_databases,delivery,analysis— in Darling's spellings and document order, resolved fromBuildAlertSettingsPayloadrather than guessed.Two spellings would have been wrong if guessed, which is the argument for reading the other side rather than inferring it:
low_disknests the critical floors ascritical_free_percent/critical_free_gb, dropping the "disk" that Lite's ownApp.AlertDiskCriticalFree*statics carry; anddelivery.modeis a second value-level translation alongsidecpu.mode, though it is the one case whereToString()is correct rather than a mapping, sinceAlertNotificationModeis the shared enum and Darling's store holds literally itsToString().self_alertsis deliberately not emitted. It is genuinely Darling-only:AppAlertEngineSettingsreturns hardcoded constants for three of its four members because Lite has no headless store volume or fleet collection loop, and has no member at all forstore_job_cadence_warn_percent. Emitting constants under knob-shaped names would advertise tunability Lite does not have.Scope 1 only, as planned — no
update_alert_settingsfor Lite. The coherency problem is unchanged and still needs a design decision: Lite's settings live inApp.Alert*statics, andSaveAlertSettingsreads its CONTROLS rather than those statics, so an open Settings window would silently overwrite an MCP-applied change. That remains the blocker for scopes 2 and 3.Two adjacent defects surfaced while matching the two payloads, both verified and split out to #2415 rather than folded in here — they are Darling-side and this issue is Lite-side.
Give Lite the AG and connection groups Darling now emits