Notifications
Clear all
Topic starter
20/08/2026 5:32 pm
TL;DR: MCP servers often behave as black boxes because they expose little or no telemetry, leaving operations teams unable to measure request rates, latency, errors, or tool usage, according to Stacklok. The article argues that proxy-based observability can close that gap without server changes, and that the real issue is governance of opaque AI-to-tool interfaces, not just dashboard coverage.
NHIMG editorial — based on content published by Stacklok: Bridging the observability gap in MCP servers with ToolHive
Questions worth separating out
Q: How should teams monitor MCP servers that do not expose telemetry?
A: Use a boundary control such as a proxy or sidecar to collect request counts, latency, errors, and tool usage before the traffic reaches the MCP server.
Q: Why do MCP servers create governance problems for AI workloads?
A: Because they mediate tool access for AI systems while often leaving little trace of what happened inside the interaction.
Q: What do organisations get wrong about AI observability?
A: They often confuse technical telemetry with governance evidence.
Practitioner guidance
- Instrument the MCP traffic path Deploy a proxy or sidecar that can observe MCP request and response flow before the server reaches production at scale.
- Standardise telemetry into OTel and Prometheus Route MCP metrics and traces through the same OpenTelemetry and Prometheus pipeline used for other Kubernetes workloads.
- Correlate tool usage with access governance Review which MCP tools are called most often, which workloads call them, and whether those patterns align with the permissions that were intended.
What's in the full article
Stacklok's full how-to covers the operational detail this post intentionally leaves for the source:
- Step-by-step deployment patterns for running ToolHive natively in Kubernetes across different cluster topologies
- Concrete metric names, trace flows, and dashboard inputs for building MCP-specific monitoring views
- Architecture trade-offs between push, scrape, and hybrid telemetry paths for reliability and latency handling
- Implementation guidance for integrating MCP observations into existing alerting and troubleshooting workflows
👉 Read Stacklok's how-to on bridging MCP observability gaps with ToolHive →
MCP server observability gaps: are your controls keeping up?
Explore further
20/08/2026 6:19 pm
Opaque MCP telemetry creates a governance gap, not just a monitoring gap. When AI systems reach tools through MCP servers, the organisation may have access control on paper but no usable evidence of how that access is exercised. That weakens auditability, incident triage, and policy enforcement at the same time. The practical conclusion is that tool visibility has to be treated as part of control assurance, not as optional engineering polish.
A question worth separating out:
Q: How can organisations reduce risk when MCP telemetry is missing?
A: Start by centralising traffic through a monitored layer, then feed that data into standard alerting and review processes. Add labels for namespace, service, and workload so the records are useful for both troubleshooting and governance. If an AI-connected service remains opaque, treat it as an exception until visibility is restored.
👉 Read our full editorial: MCP server observability gaps are now an operational risk
