MCP server observability is becoming a control plane for AI tools

At a glance

What this is: Agnost is an MCP server analytics platform focused on tool invocations, latency, errors, and user journeys across AI clients.

Why it matters: MCP observability matters because identity teams need to understand how AI-connected tools are being used before they can govern access, troubleshoot failures, or bound exposure across NHI and emerging agentic workflows.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read WorkOS's analysis of Agnost AI for MCP server observability

Context

MCP server observability is the missing layer between AI clients and the tools they invoke. When tool calls happen asynchronously across Claude Desktop, VS Code, and API-driven workflows, teams lose basic visibility into what was called, who called it, and why failures occurred. That creates an identity governance gap for MCP server analytics, because access scope and runtime behaviour are no longer easy to reconcile.

For IAM and NHI teams, the problem is not monitoring volume alone. It is understanding whether tool permissions, session behaviour, and error patterns align with the access model that was approved, especially when the same MCP server is reused across multiple AI clients and production paths. In practice, that makes MCP server analytics part of the control surface, not a nice-to-have dashboard.

Key questions

Q: How should security teams govern MCP servers used by multiple AI clients?

A: Security teams should treat a shared MCP server as a governed access path, not a generic integration. Document which clients may use it, which tools are permitted, and which sessions are allowed to reach production data. Then compare those approvals with observed tool-call telemetry so you can see where actual usage diverges from the intended trust model.

Q: Why do MCP servers create new visibility gaps for IAM teams?

A: MCP servers create visibility gaps because tool invocation happens inside AI-mediated sessions that span multiple clients and often lack a clean audit trail. IAM teams may know the server exists, but not which tool was called, from which client, or whether the call matched the approved access scope. That makes runtime evidence essential for governance.

Q: What breaks when tool usage is not correlated across AI clients?

A: When tool usage is not correlated across AI clients, teams lose the ability to reconstruct a complete user journey. That makes it difficult to diagnose failures, investigate misuse, or prove that access stayed within scope. The same server may appear compliant in one client and risky in another, which hides the real control failure.

Q: How do security teams decide whether MCP observability is enough?

A: MCP observability is enough only when it produces actionable evidence for ownership, scope, and session-level behaviour. If the telemetry cannot show who invoked a tool, which client initiated the call, and whether the action matched the approved workflow, then the organisation still lacks governable identity evidence.

Technical breakdown

MCP server instrumentation and tool-call telemetry

MCP servers sit between an AI client and the external tools it can invoke, so the useful telemetry is not just HTTP traffic or application logs. The important events are tool invocation, latency, error type, client source, and session linkage. A lightweight wrapper can intercept those calls without changing server logic, which is why single-line instrumentation is attractive. The technical value comes from making each tool call observable as a discrete identity-relevant event, not from general application monitoring.

Practical implication: instrument tool calls at the MCP layer so access, performance, and failure data can be reviewed against the intended permissions model.

User journeys across multiple AI clients

MCP usage rarely lives inside one interface. The same server may serve Claude Desktop, VS Code, and API clients, with journeys that span multiple sessions and tools. That creates a fragmented audit trail unless the platform correlates events into a single user story. The architectural challenge is joining invocation, timing, and outcome data across clients so teams can reconstruct what happened without treating each request in isolation.

Practical implication: correlate MCP events across clients before you try to diagnose abuse, drift, or reliability issues.

Latency and error patterns as governance signals

Latency percentiles and error captures are operational metrics, but they also reveal governance failures. A slow or failing tool may indicate over-broad access paths, brittle dependencies, or poor separation between user intent and tool execution. In MCP environments, those signals matter because the user experience and the security posture often degrade together. Observability becomes useful when it can distinguish a broken tool from a mis-scoped one.

Practical implication: treat repeated latency spikes and error clusters as prompts to review tool scope, dependency design, and client-specific access paths.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP observability is now an identity governance problem, not just an engineering convenience. Once AI clients invoke tools through MCP, each tool call becomes a governed access event that should be inspectable, attributable, and bounded. The operational question is no longer whether the server is up, but whether its runtime behaviour matches the permissions model that was approved. Practitioners should treat MCP analytics as part of access governance for non-human identities.

Tool-call visibility exposes the gap between approved access and actual behaviour. Teams often approve an MCP server as though the access path were static, yet the real usage pattern depends on client choice, session context, and tool sequencing. That is where hidden privilege creep appears in practice. Runtime tool usage drift: a server can remain within its nominal configuration while repeatedly exercising paths that were never reviewed in context. Practitioners need to govern the executed path, not only the configured entitlement.

The control failure here is blind delegation across AI clients. When the same MCP server is reused in different clients, owners may assume one access model covers all use cases. In reality, the effective trust boundary changes with each client, session, and integration path. That means review cycles built around static inventories will miss the actual risk surface. Practitioners should reframe MCP oversight as delegated access control with runtime evidence.

MCP analytics will increasingly define how teams separate experimentation from production risk. As MCP servers move from pilot use into production workflows, the difference between an isolated test and an enterprise control point narrows fast. Visibility into tool invocations, latency, and error patterns provides the evidence needed to decide where to permit scale and where to constrain it. The practical conclusion is simple: if you cannot observe it, you cannot govern it.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• A separate finding shows 53% of MCP servers expose credentials through hard-coded values in configuration files, which turns visibility gaps into direct secret-exposure risk.
• For a broader view of how AI-driven access paths change governance, see OWASP Agentic AI Top 10 for runtime identity and tool-misuse risks.

What this signals

MCP server analytics will become part of the access governance stack as AI clients spread across the enterprise. The teams that can correlate tool calls, latency, and user journeys will be able to explain not just what the server did, but whether it behaved within the intended permission boundary. That makes observability a prerequisite for scaling AI-connected workflows, not a later optimisation.

Runtime evidence will matter more than configuration claims. If the access model looks clean but the telemetry shows repeated cross-client usage, unusual tool concentration, or failure clusters, the governance posture is already weaker than the documentation suggests. The practical shift is toward evidence-led review, where runtime behaviour drives entitlement decisions.

Use OWASP Agentic AI Top 10 and NIST AI Risk Management Framework together when MCP servers sit behind autonomous or semi-autonomous workflows. The control question is not only whether the tools are available, but whether their use remains attributable, bounded, and reviewable as AI-mediated execution expands. For practitioner teams, that is the difference between monitored integration and unmanaged delegation.

For practitioners

• Map each MCP server to an explicit access owner Assign a human or platform owner to every MCP server and document which AI clients may invoke it, which tools are in scope, and which environments are approved for use. Keep that mapping aligned with the actual runtime paths you observe in telemetry.
• Review tool permissions against observed usage Compare approved tool scope with actual invocation patterns, especially when a single server serves Claude Desktop, VS Code, and API clients. Flag tools that are rarely used, unexpectedly common, or invoked from unapproved client contexts.
• Treat error spikes as access-scope signals Investigate repeated failures, unusual latency bands, and client-specific error clusters as potential indicators of brittle authorization paths or over-broad tool exposure. Use the telemetry to separate infrastructure issues from governance issues.
• Instrument MCP analytics before production rollout Require telemetry and session correlation before exposing an MCP server to shared teams or business-critical workflows. Without that baseline, you cannot distinguish safe adoption from unreviewed access expansion.

Key takeaways

• MCP server analytics turns tool invocation into governable identity evidence, which is essential once AI clients begin sharing the same access path.
• The scale of the access problem is already visible, with many MCP deployments still lacking scoping and exposing hard-coded credentials.
• Teams should align observed tool usage, client context, and ownership before MCP servers are allowed to support production workflows.

Key terms

• Mcp Server: An MCP server is an intermediary service that lets an AI client reach tools, APIs, or data sources through a standard protocol. In governance terms, it becomes a non-human access broker, so its permissions, logging, and client boundaries matter as much as the tools it exposes.
• Tool Invocation Telemetry: Tool invocation telemetry is the event data generated when an AI client calls a tool through an MCP server. It typically includes the tool name, timing, outcome, and source client, giving identity and security teams the evidence needed to review runtime behaviour rather than just configuration.
• Client Distribution: Client distribution describes how MCP traffic is split across different AI applications such as Claude Desktop, VS Code, or API-based clients. It matters because the same server can behave differently across clients, changing the effective trust boundary and making one-size-fits-all access assumptions unreliable.

Deepen your knowledge

MCP server observability and tool-call governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-connected workflows or shared server access, it is worth exploring.

This post draws on content published by WorkOS: What is Agnost AI? An MCP server analytics platform. Read the original.