Connector diagnostics need semantic alerts, not just successful MCP calls

A diagnostic tool can execute successfully while reporting that its downstream service is unhealthy. Monitor the documented diagnostic status and reason, independently of HTTP/MCP success and gateway liveness. Keep this interpretation in the external monitor or the leaf's health contract; a thin gateway should not infer business health from arbitrary tool payloads.

For a minimal monitor, periodically make authenticated MCP initialize and tools/list requests, compare expected tool namespaces for the exact route and access tier, then run a small allowlist of read-only diagnostics. Check diagnostic bodies for healthy status, and emit only source, safe error category, duration and release version. Alert after repeated failures, deduplicate by source/category, notify on recovery, and alert when monitor runs stop arriving. Exercise one controlled failure and recovery to verify actual notification delivery. A direct MCP probe validates server availability, authorization, discovery and selected execution; it does not establish that Claude's tool-search selected or refreshed those tools. Use a separate client acceptance test for that boundary.

Applies when: MCP diagnostics or API health reports return normal transport responses containing unhealthy downstream status. Keywords: MCP diagnostics health alerts authentication discovery monitoring semantic success Salesforce