MCP Server Monitoring and Observability: What to Track
An MCP server called by an AI model fails differently than a normal API. Here is what to actually monitor: request volume, latency, error rate, and the specific things that go wrong with AI-initiated calls.
Monitoring an MCP server matters more than monitoring a typical internal API, because the caller isn't a developer who read your documentation. It's an AI model deciding autonomously when and how to call your tools, based on a user's request and whatever context it has. When something goes wrong, you often can't ask the caller what they meant. You need the logs to tell you.
What to Track
Request volume, per tool
Aggregate request counts at the server level hide which tools are actually being used. Track volume per tool so you know which ones matter and which ones nobody calls. This also makes an unusual spike much easier to notice: a 10x jump in calls to one specific tool is a clearer signal than a smaller change in overall traffic.
Latency, per tool
Different tools have very different normal latency. A tool that queries a local cache should respond in milliseconds; one that calls a third-party API might normally take a few seconds. Tracking latency per tool, not just at the server level, lets you set realistic expectations and actually notice regressions.
Error rate, and the full error context
An error rate number alone tells you something is wrong. It doesn't tell you what. For every failed call, capture:
- The full stack trace
- The input parameters the tool was called with
- Any partial output before the failure
return { content: [{type: "text", text: `Failed to fetch weather: ${error.message}`}], isError: true, };
Returning the error through isError: true instead of throwing an uncaught exception keeps the AI's context clean, since it tells the model the call completed but the operation failed, which it can often handle gracefully (retrying, or telling the user) rather than surfacing a raw stack trace.
Cost, per tool and per server
If your tools call metered third-party APIs, cost tracking at the tool level is what tells you which tool is actually expensive to run, as opposed to which one is called most often. Those are not always the same tool.
Geographic and client distribution
Knowing where requests originate and which AI client is calling helps you spot both legitimate usage patterns and suspicious ones, such as traffic from a region or client you don't expect.
What's Different About AI-Initiated Traffic
A few monitoring patterns matter more for MCP servers than for typical APIs:
Retry storms. An AI encountering a transient error may retry more aggressively or differently than a typical client library, especially if the tool's error message doesn't clearly signal "don't retry this." Watch for repeated identical calls in a short window.
Parameter drift. Because an AI model infers tool parameters from context rather than a fixed client codebase, you'll see a wider variety of input shapes than a traditional API typically gets. Logging actual input parameters (not just that a call happened) is what lets you tell the difference between a bug in your validation and a legitimately unusual but valid request.
Silent misuse. A tool description that's ambiguous can lead an AI to call the right tool in the wrong situation. This doesn't always show up as an error. Reviewing what parameters a tool is actually being called with over time can reveal that a description needs to be more specific, even when nothing is technically failing.
Building This Yourself vs Getting It Built In
Wiring up per-tool latency, cost, and error tracking from scratch means integrating a logging service (Datadog, Grafana, or similar), instrumenting every tool call, and building dashboards on top. It's a reasonable amount of work for a single server and a meaningfully larger amount of work to do consistently across many.
MCPCore tracks all of this automatically for every server: real-time request volume, per-tool latency, cost over time, geographic distribution, and full stack traces on every failed call, with no logging code to write. See MCP server analytics for what's included.
Monitoring recommendations reflect general MCP server operating experience. Response and cache-related fields in the current spec (such as ttlMs on list results) can also factor into what you monitor. Check modelcontextprotocol.io for the current specification.