Topic starter
20/08/2026 5:32 pm
TL;DR: MCP servers often run with little or no telemetry, Stacklok notes, so teams cannot measure request volume, latency, errors or tool usage. Proxy-based visibility can fill the gap, but MCP paths need attribution and runtime accountability before production.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Bridging the observability gap in MCP servers with ToolHive”.
Key questions
Q: Why does missing observability increase risk for AI toolchains?
A: Because AI-connected services can trigger real actions in downstream systems, and those actions need attribution, measurement, and review.
Q: How should teams detect that MCP visibility is failing?
A: Look for absent metrics, missing traces, flat request counts, unexplained latency blind spots, and tool usage that cannot be tied back to specific workloads.
Q: What breaks when MCP servers do not expose telemetry in Kubernetes?
A: Teams lose the ability to trace tool use, identify which service handled a request, and distinguish normal automation from risky behaviour.
Practitioner guidance
- Define telemetry readiness for MCP services Require every MCP server to declare how request counts, latency, tool usage, and error states will be observed before production approval.
- Insert a proxy at the runtime boundary Place an observability proxy where MCP traffic passes so that measurement does not depend on server-side code changes or instrumented endpoints.
- Correlate tool usage with workload identity Tie MCP request metrics to namespace, pod, and service context so teams can distinguish normal tool invocation from unexpected AI-driven behavior.
Bottom line: MCP servers that do not emit metrics or traces create a governance problem as much as an operational one, because teams cannot see how AI-to-tool interactions behave in production.
Glossary terms: Model Context Protocol, Protocol-opaque Service Exposure, Gateway-Based Observability, Telemetry Readiness
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
20/08/2026 6:19 pm
Observability debt is becoming governance debt for AI-to-tool interfaces. When an MCP server cannot expose reliable telemetry, the organisation cannot prove how that server behaves under load, how often tools are invoked, or whether usage aligns with intended purpose. That makes the issue relevant to runtime governance, not just SRE hygiene. For identity and access programmes, the lesson is that trust in AI-connected services now depends on measurable behavior.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should organisations use proxy-based observability for MCP services?
A: Use it when the server cannot expose telemetry itself, when production rollout cannot wait for code changes, or when the organisation needs standard metrics in an existing OTel and Prometheus pipeline. The proxy is most useful when observability must be added without disrupting the service.
👉 Read our full editorial: MCP server observability gaps are now an operational risk