MCP Observability Tools for Enterprise AI Agents

Real-time observability for MCP-connected data access means capturing tool calls at a shared gateway and linking them to the agent sessions, access identities, policy decisions, and data-handling events they belong to. The gateway sees only traffic routed through it, so bypass paths remain blind spots. MCP observability is a distinct infrastructure decision.

Why MCP observability is a different infrastructure problem from LLM monitoring

LLM monitoring records prompts, completions, tokens, and latency for a model turn. It does not explain the actions that follow. One user request can set off several model turns and tool calls over live data connections, and each action can use a different access identity. The unit that needs tracing is the whole agent session.

The Model Context Protocol, or MCP, makes that action half possible across multiple servers. Standard application performance monitoring can record HTTP 200 and a fast response without showing which tool ran, what data it touched, or whether an injected instruction changed the agent’s behavior. A successful request can still be a harmful action. Traditional monitoring was built for deterministic services and failures that return error codes, but agents can choose different tools for the same prompt based on the context.

That difference is harder to manage when employees’ tools connect to more servers. Claude Desktop, Cursor, and VS Code are common ways in, and developers and non-developers can add servers without anyone reviewing them. Ownership and logging then vary across the access layer. The enterprise may know that an application is running without knowing which MCP servers it lets an agent reach.

How do teams monitor what data agents access through MCP, and what must they capture?

After an incident, the first question is who initiated the action and under whose authority. The record needs the user or agent, the MCP client or host, the server, and the specific tool, prompt, or resource invoked. Request parameters and response metadata show what passed through that connection. A CRM endpoint log alone may not show that an agent called it for a particular user inside a particular conversation.

Authentication and authorization decisions need to sit beside policy checks, filters, denials, and modifications, rather than in records that cannot be joined to the call. Security teams also need to know whether PII or secrets were detected, blocked, redacted, or allowed. Latency cannot answer any of those questions. Tool calls may read files, search records, create tickets, send messages, or trigger workflows, so their consequences extend beyond backend performance.

Teams reviewing an incident also need to know when the action happened, whether it failed, and how it fits the wider pattern of use. Timing, latency, errors, and audit records supply that context, while per-execution cost tracking shows the accumulated token cost of chained model calls. The capture boundary is expanding further. MCP Apps can return interactive UI components, and elicitation lets servers ask for structured input during a task, but traditional trace models do not fully show either. Compliance frameworks now explicitly require agent-activity traceability for many enterprises, making these records more than optional debugging aids.

Why per-server logging and SDK instrumentation cannot close the gap on their own

A server log knows only its own part. SDK instrumentation can trace what an application does, but without shared context propagation, the agent and server create separate records that do not show who was responsible across the whole call chain. Someone has to join those records by hand later, and the order of calls across servers is lost.

SDK coverage also depends on someone instrumenting the application. Coding agents on developer machines, employee-installed AI apps, and agents outside an instrumented framework fall outside that boundary. Server logs cannot reliably fill the hole. MCP’s historical logging guidance left comprehensive audit requirements to implementors, so some servers omit logging while others record only minimal operational metadata. The July 2026 specification revision deprecated protocol-level logging in favor of stderr for stdio transports or OpenTelemetry for structured observability, but that change does not repair older implementations.

A shared gateway provides a place to join the traffic, but the objection to it is serious. It creates a single point of failure and concentrates credentials for enterprise systems. The gateway itself therefore needs governance, including scoped credentials, role-based access control, audit trails, and per-agent or per-tool revocation.

Sensitive data returned by a tool can enter model context, be logged, reach an LLM provider, or leak through later calls before an observability system flags it. That residual risk is why capture and access enforcement need to be evaluated separately, even when one layer provides both.

How the OpenTelemetry GenAI semantic conventions create a common language for MCP traces — and where they still fall short

OpenTelemetry’s GenAI semantic conventions define common gen_ai.* span and metric attributes that instrumentation libraries can emit and backends can ingest. That vocabulary separates the capture code from the choice of analysis platform. Portability starts with a shared meaning for fields. Without it, exporting traces can move the data while leaving each backend to interpret it differently.

OpenTelemetry added MCP semantic conventions in v1.39, including mcp.method.name, mcp.session.id, and mcp.protocol.version. Those attributes show the protocol details in traces that would otherwise show tool activity as generic requests. The conventions are still moving, however. On June 12, 2026, v1.42.0 moved the GenAI conventions and MCP conventions into the dedicated semantic-conventions-genai repository so they could develop faster than the core stability requirements allow.

As of August 21, 2026, that repository has no official release and marks the GenAI conventions as “Development”. A claim of stable OpenTelemetry GenAI support therefore needs qualification. The conventions standardize model attributes, token usage, and latency, but do not cover output evaluation, safety scoring, or content quality assessment. Common telemetry fields make tools more comparable. They do not prove that a tool captures every agent, judges its output, or enforces access policy.

What the main tool categories can and cannot see, and the coverage trade-off each forces

Gateway capture has the broadest view when all clients reach all MCP servers through it. That position can join calling identity, session, parameters, responses, latency, and timestamps across servers without requiring application code changes.

Bifrost is an open-source, self-hostable AI gateway that records LLM requests and MCP tool calls routed through it. Export destinations include Prometheus, OpenTelemetry backends, and Datadog. Session grouping requires an explicit configuration choice. Bifrost can group a Claude Code, Codex CLI, or OpenCode run using the session header those agents send, but group_traces_by_session defaults to false.

SDK instrumentation trades that shared capture position for depth inside instrumented applications. Datadog LLM Observability captures activity from session initialization to tool invocation, supports manual instrumentation for non-official SDKs, and connects traces with prompt quality and functional evaluation. It treats MCP activity as operational and audit data. Its boundary is still the instrumented application. An agent that an employee installs outside that boundary stays out of view even if the analysis backend supports MCP traces.

An analysis backend and an MCP server also serve different roles. Datadog’s Remote MCP Server became generally available on March 9, 2026, is HIPAA-eligible, and uses OAuth authentication. Server availability is not evidence of monitoring coverage. Buyers need to distinguish a product that exposes tools through MCP from the mechanism that records agents using them.

The Prometheus MCP Server is an open-source bridge between LLM implementations and the Prometheus monitoring platform. Its question-driven access to monitoring data fits teams already using Prometheus for metrics, but that connectivity role is not equivalent to gateway capture. Some APM integrations offer 100+ tools that use up context-window tokens, so teams have to choose which tools to load.

The security incidents that make ungoverned MCP servers an observability failure, not just a security gap

Incidents in 2025 included cross-tenant data exposure at Asana, prompt injection attacks against the GitHub MCP server, unauthenticated remote code execution in Anthropic’s MCP Inspector developer tool, and supply chain compromises through malicious npm packages. Each also raises an observability question about which identity acted, which server or tool it reached, and what happened next.

To find out how data crossed a tenant boundary in the Asana exposure, teams need the access identity and authorization records. The GitHub attacks make both the agent’s sequence of tool calls and the status of individual requests relevant. The Inspector and malicious-package incidents put server provenance and ownership under scrutiny. These are questions a capture layer should support. The incidents alone do not show that monitoring would have stopped exploitation, and collecting traces does not fix a vulnerability.

The August 2026 Deadbugz campaign makes the session requirement especially concrete. It spread a malicious MCP server called “productivity-suite” through public GitHub pull requests. After three ordinary tool calls, the server changed its instructions and directed the agent to search for SSH keys, AWS credentials, shell history, and Kubernetes configuration while hiding the activity from the user. The early calls were part of the disguise. Session-level capture would let a reviewer link the ordinary activity to the later search for credentials, a link lost when each call is reviewed on its own.

Infrastructure outside the server also needs scrutiny. Between January and February 2026, researchers filed a wave of CVEs for flaws in MCP servers, clients, and infrastructure components. JFrog identified CVE-2025-6514 in the widely used mcp-remote proxy package with a CVSS score of 9.6. The July 2026 specification revision strengthens authorization and removes the session-ID mechanism, primarily for operational and scalability reasons. Older servers still need auditing.

What enterprises should evaluate before choosing an observability approach

The evaluation should begin with the agents a tool cannot see. A team choosing SDK instrumentation needs to account for coding agents, employee-installed apps, and applications outside its instrumented frameworks. A team choosing a gateway needs to account for direct connections that bypass it. Coverage comes before the dashboard comparison. Later features need evidence collected at the capture point.

Attribution is the next test. The tool should connect each call to an agent identity, session, team, or virtual key, then group multi-request, multi-server activity into one traceable run. Per-call records need the tool name, server, duration, error type, and parameters. Timing is a separate requirement. An audit log supports investigation after an incident, while real-time visibility shows what the agent is touching as it operates.

Portability and deployment determine where that evidence can go. Enterprises should evaluate OTLP export, GenAI semantic conventions, and Prometheus-compatible metrics as ways to keep telemetry usable across backends. They should also compare self-hosted, in-VPC, and SaaS deployment because prompts and tool responses frequently contain regulated content. Capture itself can cross a sensitive-data boundary. Teams should also check the controls for selective tool-loading, especially when large tool catalogs use up context before the agent starts work.

Finally, the gateway must be evaluated as an access-control system. Enterprises that need enforcement should look for RBAC, credential scoping, a server registry, and revocation per agent or server, with audit trails covering the gateway itself. An unregistered server leaves an access identity unaccounted for. Enterprises should make this infrastructure decision before production because the attack surface is there as soon as a server goes ungoverned.