MCP alert-settings tools say webhook delivery is "managed separately" but never say where #2709

Context

While scoping a broader alerting-integration effort (Datadog-alert-structure parity for outbound payloads, and a Postgres-vs-SQL-Server alert-type coverage audit — both being tracked as sibling issues), I went looking for how a headless Darling deployment configures Slack/Teams/PagerDuty/generic-webhook alert delivery, since update_alert_settings (Darling/PerformanceMonitor.Darling.Service/Mcp/DarlingMcpAlertTools.cs:322) and get_alert_settings (:127) both say, verbatim, "SMTP/webhook delivery credentials are managed separately and cannot be set here" / "are managed separately and are not reported here" — with no pointer to what "separately" means.

Correcting an assumption I initially made: I first assumed this meant there was no headless-safe configuration path at all (Darling has no desktop UI of its own). That's wrong, and I want to log the corrected finding rather than the wrong premise.

What actually exists (already fully built, not a gap)

• The multi-channel delivery pipeline (Slack, Teams, PagerDuty Events API v2, and a fully generic/templatable webhook channel per [QUESTION] Connection is broken: need PM restart ? #1506) is implemented in PerformanceMonitor.Notifications/WebhookAlertService.cs, driven by config.config_notification (schema added across V17/V25/V26/V42/V43+ in PgMigrations.cs).
• PerformanceMonitor.Darling.Viewer (the separate WPF Viewer app) already has a full Settings-window UI for this — SettingsWindow.xaml.cs seeds/saves Email, Teams, Slack, PagerDuty, and generic-webhook sections, writing through ViewerDataService.Notification.cs's NotificationUpsertSql directly into config_notification. The running service (StoreConfigProvider, Stage-1) reads and hot-swaps the new config into its live SmtpConfig/WebhooksConfig with no restart needed.
• The Viewer's Postgres connection is not hardcoded to localhost — ViewerDataService takes an arbitrary Npgsql connection string, and ViewerSettings.cs explicitly distinguishes the managed single-box default (127.0.0.1) from a configured remote target. This is exactly the "remote Viewer connection" path the internal DarlingConnectionGuide.md (SQLServerSetup repo) already documents for teammates reaching a headless box's store.
• Secret handling for these columns is a deliberate, already-reasoned design, not an oversight: pagerduty_routing_key/teams_url/slack_url/generic_url/generic_headers are stored as plaintext but column-REVOKEd from the read-only viewer role (DarlingManagedRoles.ViewerRestrictedConfigTables, documented at PgMigrations.cs:826-832) — the same tier as the SMTP password, except the SMTP password additionally gets DPAPI-LocalMachine encryption because viewer+service share one machine's DPAPI key in the managed single-box deploy. That DPAPI approach would NOT generalize to the webhook columns once a remote Viewer is configuring a different machine's service (DPAPI is machine-scoped — encrypting on the viewer's box would produce a blob the service's box cannot decrypt), so plaintext + role-REVOKE is the correct tradeoff here, not a bug to fix.

The actual, narrow gap

None of the above is discoverable from the headless service's own surface. darling.exe --help has zero mentions of notification configuration. The two MCP tool descriptions say "managed separately" and stop there. An operator (or an agent working on the operator's behalf) reading only the CLI/MCP surface — the parts of this project most likely to be consulted first for a headless deployment — has no way to learn that the answer is "run the standalone Viewer app, point it at this store's connection string, open Settings → Notifications." I got this wrong myself before tracing the actual code.

Options (scoping only, not committing to one)

1. Extend the two MCP tool descriptions' "managed separately" sentence with a one-clause pointer, e.g. "— run the PerformanceMonitor Darling Viewer app, connected to this store, and use Settings → Notifications."
2. Add a darling.exe --help line (or a dedicated darling.exe notifications-help no-op command) stating the same.
3. A short doc file in this repo (e.g. docs/alert-delivery-configuration.md) that both the CLI help and the MCP descriptions can point at, covering the Viewer path and the remote-connection prerequisite — this repo doesn't currently carry that internal connection-guide content, only the SQLServerSetup-repo doc does.

Filed as part of a broader alerting-integration scoping pass; two sibling issues cover the Datadog-alert-payload-parity gap and the Postgres/SQL-Server alert-type coverage gap.