Topic starter
07/06/2026 8:53 pm
TL;DR: MCP servers connect AI clients to tools and data, but their asynchronous calls, cross-client journeys, and hidden error patterns make usage and latency hard to govern without dedicated observability, according to WorkOS. That visibility gap matters because tool-level monitoring is now part of identity and access control for AI-mediated workflows.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “What is Agnost AI? An MCP server analytics platform”.
By the numbers:
- Agnost's dashboard example shows 6,026 total invocations, a 97.34% average success rate, and latency percentiles of p50, p90, and p99.
Key questions
Q: What breaks when MCP observability is missing?
A: Root cause analysis breaks first, followed by cost attribution, policy enforcement, and safe incident response.
Q: Why do MCP tool calls need more than ordinary application logs?
A: Because MCP calls are asynchronous and often span multiple clients and sessions, ordinary logs usually miss the relationship between the user journey, the tool selected, and the end result.
Q: How should security teams govern MCP servers used by AI coding assistants?
A: Treat MCP servers as privileged trust boundaries, not simple data sources.
Practitioner guidance
- Instrument MCP servers at the tool layer Capture tool invocation, latency, error, and user-journey data where the MCP server mediates access, not only in downstream application logs.
- Separate client behaviour from backend performance Use per-client and per-tool telemetry to identify whether slow or failing workflows come from the AI client, the MCP server, or the target system.
- Define reviewable ownership for MCP telemetry Assign responsibility for monitoring, alerting, and investigation so tool execution data can support governance and incident triage.
Bottom line: MCP servers now sit on the AI tool execution path, so their telemetry has direct governance value for identity and access programmes.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 8:36 am
MCP observability is becoming an access-control dependency, not just an engineering convenience. Once AI clients rely on MCP servers to reach tools and data, the server sits inside the execution path that identity teams need to govern. Without tool-level telemetry, access decisions become partially unverifiable because the organisation cannot reconstruct who invoked what, through which client, and in what sequence. The practitioner conclusion is simple: visibility now sits on the critical path for AI tool governance.
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.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between traditional observability and MCP observability?
A: Traditional observability asks what happened: a request was made, it took a certain time, and it returned a status. MCP observability must answer whether the call should have happened at all. That means linking the initiating user or service, the executing agent, the session history, and the tool semantics so teams can evaluate intent, not just transport behavior.
👉 Read our full editorial: MCP server observability is becoming a control plane for AI tools
This post was modified 4 days ago by NHI Mgmt Group