MCP Observability: How to Monitor an MCP Server in Production

Updated September 2026

MCP observability is the practice of understanding how AI agents use a Model Context Protocol server in production, from server health and tool calls through the user intent that triggered them and the outcome the agent ultimately delivered. It answers both "is the server healthy?" and "did this tool journey work for the person who started it?"

That second question is the gap. A dashboard can show low latency and a high tool success rate while users still repeat requests, agents choose the wrong tool, workflows stop halfway, or the final answer claims work that never happened.

MCP monitoring versus MCP observability

Monitoring evaluates known conditions. Observability helps a team investigate conditions it did not predict. Both matter, but they operate at different levels.

Traditional application performance monitoring is strongest in the first three rows. Agent tracing often covers the fourth. Production MCP teams also need the last three if the server is a product interface rather than an internal utility.

A running example: the sales brief that never became useful

Imagine an MCP server with tools for finding an account, reading recent activity, and drafting a sales brief. The server is technically healthy:

• Every request returns within the latency objective.
• Authentication succeeds.
• Each selected tool reports success.
• No exception reaches the error tracker.

The complete session tells a different story. The agent searches for the same account three times, never retrieves the latest activity, drafts a generic summary, and asks the user to paste information the server already exposes.

At the call level, the system looks green. At the user level, it failed. The right investigation starts with the attempted job, follows the full path, compares it with successful briefs, and opens the exact sessions behind the repeated pattern.

Tool success is not user success

Five distinctions prevent misleading MCP dashboards:

1. Transport success is not tool success. An HTTP response can succeed while the tool reports a domain error.
2. Tool success is not workflow completion. A valid search result does not prove the requested report was produced.
3. Workflow completion is not outcome quality. An artifact can exist and still be wrong or unusable.
4. A reported outcome is not always a verified outcome. Prefer external confirmation when the business action can be checked.
5. A tool error is not always user failure. An agent may recover, change parameters, choose another tool, and still complete the job.

Keep unknown outcomes visible. If 700 of 1,000 sessions have a measurable result, report both the result among those 700 and the 70% coverage. Converting the remaining 300 into success or failure hides the most important telemetry gap.

The MCP metrics that matter

Infrastructure and protocol health

• Availability and request throughput
• Latency percentiles by operation and transport
• Authentication and authorization failures
• Resource saturation and downstream dependency errors
• Protocol and client-version distribution
• Telemetry delivery health

These metrics answer whether the server can serve traffic. They remain essential even when product analytics is the main goal.

Tool execution

• Calls and unique sessions by tool
• Success, domain error, timeout, and cancellation rates
• Retry and repeated-call frequency
• Tools exposed but rarely selected
• Result and evaluation coverage
• Changes by server release or client

Raw volume is useful for capacity planning, not as a product success metric. A tool can become popular because it is valuable or because agents keep calling it unsuccessfully.

Sessions and journeys

• Unique attempted use cases
• Tools per completed and incomplete session
• Common tool paths for the same intent
• Completion, partial completion, failure, and unknown outcome
• Abandonment before an expected step
• Time and turns to a meaningful result

The modern MCP core is stateless at the protocol layer. That does not make the user's work a single-call event. Product teams still need an application-level view of related calls when they have a permitted way to establish it.

Behavioral and product signals

• Equivalent calls repeated without new information
• Wrong-tool selection and unnecessary tool switching
• Confident completion claims without supporting evidence
• User corrections and reformulations
• Requests for capabilities the server does not expose
• Feedback themes and high-value commercial intent
• Issue incidence by user, account, client, or use case

These signals should lead to inspectable sessions. A detector is a prioritization aid, not proof of root cause by itself.

How OpenTelemetry fits

OpenTelemetry ↗ provides a vendor-neutral way to create and export telemetry. Its semantic conventions give common meaning to operations, and its tracing model connects work across service boundaries.

OpenTelemetry's context propagation guide ↗ explains how W3C Trace Context connects work across services. MCP SDK support must be checked separately: the official PHP SDK documents trace-context passthrough ↗, for example. Verify the actual client, server, and downstream path instead of assuming every MCP integration propagates context.

Use OpenTelemetry to preserve the technical evidence. Then decide where each question belongs:

Flowlines does not replace the telemetry stack. It analyzes the behavioral and product layer on top of production evidence.

How to instrument an MCP server

Instrument the server at the tool execution boundary with the current official MCP SDK and OpenTelemetry guidance for your language. Capture enough approved technical context to identify the operation, measure its duration and final status, and connect it to the surrounding distributed trace. Avoid duplicate instrumentation and keep sensitive content outside telemetry unless it is necessary, permitted, and protected.

Flowlines provides OpenTelemetry-compatible MCP instrumentation through its official plugin. Developers using Claude Code or Codex can use the plugin to review a repository, agree on the data boundary, apply the supported integration, and verify a representative journey with minimal setup.

The implementation details should stay in the maintained plugin because SDKs and conventions change. The MCP OpenTelemetry guide covers the public architecture, privacy review, error model, and acceptance tests without publishing a stale drop-in snippet.

How to track MCP sessions

The product session should match the work the user initiated, not whichever transport connection or trace is easiest to count. A single journey may include several tools and requests. One tool may also serve many unrelated journeys.

Use a permitted application-level relationship to connect related calls, then validate the grouping against known examples. Keep uncorrelated calls explicit. The current MCP core is stateless, so a team should not infer a complete user journey from timestamps or similar content alone.

A useful session view includes the attempted use case, tool sequence, retries, client, permitted user or account, final status, outcome coverage, and links to the source evidence.

Server telemetry does not automatically include the AI host's full conversation or final answer. Define the boundary of what you can observe. If the intended artifact or external action is not visible, report the result as unknown or explicitly limited to the server-side workflow. Do not collect unrelated conversation content to fill the gap.

How to debug an MCP server: start with the symptom

Use a synthetic request and the same client, protocol revision, and authentication path as the failing case. Change one variable at a time.

Record the observed sequence, the remaining hypothesis, and the next test. A useful incident note says what would disprove the explanation. The instrumentation guide adds exporter, shutdown, sampling, and transport checks.

Detect silent MCP failures

A silent failure is a session that causes user harm without producing an obvious system error. Common examples include:

• The agent calls a valid tool for the wrong job.
• A search returns an empty result and the agent invents an answer.
• A write tool succeeds, but the agent misstates what changed.
• A workflow loops across two healthy tools.
• The user asks for an unsupported capability and gets a generic response.
• The final answer declares success before the necessary action occurs.

Start with a narrow, reviewable rule. Count unique sessions and users, not only calls. Inspect representative failures and successful sessions from the same intent. Record false positives. After a fix, compare a matched production window and check that telemetry coverage did not change.

How to identify MCP loops and inefficient workflows

Start with calls per completed journey, not calls per minute. Compare successful and incomplete journeys for the same use case. Repeated equivalent calls without new information, rapid switching between overlapping tools, and long paths that end in the same result are useful investigation leads.

Volume alone cannot tell whether a path is inefficient. A complex compliance check may legitimately require many tools, while a simple account lookup may be broken after three identical retries. Review the expected path with the product owner and inspect representative sessions before setting a threshold.

How to discover unmet needs from MCP traffic

Look for repeated user jobs that the current tool surface cannot complete: unsupported requests, searches across several irrelevant tools, workflows that end with manual instructions, and recurring corrections after a generic response. Group the pattern by use case, then rank it by affected users, repeat frequency, outcome impact, and account relevance.

An unmet-need detector is a research queue, not a roadmap. Validate the need with the underlying sessions and customer conversations, then decide whether the right response is a new tool, a clearer tool description, better documentation, or no product change.

How to surface product feedback and commercial intent

MCP traffic can contain product feedback, integration questions, deployment constraints, and signs of evaluation or expansion. Define the behavior that matters, restrict it to the appropriate population, and route a concise finding to a person who can review the evidence.

Do not treat a keyword as proof of intent. A security question may be buying research, troubleshooting, or routine policy work. The signal becomes useful when the account context, repeated behavior, and complete session support the same interpretation.

A practical MCP observability architecture

User
  → AI client
  → MCP server
  → OpenTelemetry-compatible instrumentation
  → operational and behavioral analysis
  → Engineering / Product / Customer / GTM

1. MCP server: emits standards-based telemetry at the tool execution boundary.
2. OpenTelemetry pipeline: processes and routes the approved telemetry.
3. Operational backend: stores traces, metrics, and logs for engineering investigation.
4. Behavioral analysis: groups calls into use cases, journeys, users, outcomes, and recurring patterns.
5. Destinations: send the relevant signal to engineering, product, customer success, or sales with evidence attached.

The architecture should preserve data ownership and let each layer do the work it is best at. A platform team may keep Grafana, Datadog, Sentry, or another backend for service reliability while product and AI teams use Flowlines to understand behavior across sessions.

Production checklist

1. Define the user jobs the server is meant to support.
2. Separate transport, tool, workflow, and business outcomes.
3. Instrument the tool execution boundary with OpenTelemetry-compatible telemetry.
4. Review what content and identity may be exported before enabling capture.
5. Propagate standard trace context where the client supports it.
6. Test one success, domain failure, timeout, recovery, and repeated-call path.
7. Confirm missing outcomes stay unknown.
8. Segment by server release, client, tool, use case, and permitted user context.
9. Attach recurring findings to representative sessions.
10. Route each alert to a named owner with a closure condition.
11. Recheck the same population after a change.
12. Monitor telemetry coverage as a product metric.

Where Flowlines fits

Flowlines MCP observability turns MCP production telemetry into server inventory, tool adoption, observed request patterns, complete use-case journeys, outcomes, recurring issues, affected users, and evidence sessions. It can sit alongside the infrastructure and tracing products a team already uses.

For implementation, read the OpenTelemetry instrumentation guide. For product questions, continue with MCP analytics. If you are selecting a stack, compare the best MCP observability tools in 2026.

Primary sources and further reading

• Model Context Protocol 2026-07-28 release ↗
• OpenTelemetry semantic conventions ↗
• Grafana MCP observability documentation ↗
• Sentry MCP monitoring announcement ↗
• Flowlines MCP product page