GoKawiilTL;DR
MCP is becoming the interface between AI agents and infrastructure data. Datadog shipped an MCP Server connecting dashboards to AI agents. Qualys flagged MCP servers as the new shadow IT risk. We think both are right, and we think the architecture should go further: the MCP server should not wrap an existing observability platform. It should BE the observability layer. This post explores how MCP can serve as a direct observability interface to kernel tracepoints, bypassing traditional metric pipelines entirely.
Three signals in one week
Three things happened in the same week of March 2026 that signal where observability is headed.
Datadog shipped an MCP Server. Their implementation connects real-time observability data to AI agents for automated detection and remediation. An AI agent can now query Datadog dashboards, pull metrics, and trigger responses through the Model Context Protocol. This is a big company validating a small protocol.
Qualys published a security analysis of MCP servers. Their TotalAI team called MCP servers “the new shadow IT for AI” and found that over 53% of servers rely on static secrets for authentication. They recommended adding observability to MCP servers: logging capability discovery events, monitoring invocation patterns, alerting on anomalies.
Cloud Native Now covered eBPF for Kubernetes network observability. Microsoft Retina deploys as a DaemonSet, captures network telemetry via eBPF without application changes, and provides kernel-level drop reasons. The article draws a clear line between “monitoring” (predefined questions) and “observability” (asking questions nobody planned for).
The thread connecting all three: AI agents need direct access to infrastructure telemetry, and MCP is becoming the way they get it.
Two approaches to MCP observability
There are two ways to connect observability data to AI agents via MCP.
... continue reading