How to monitor an MCP server

Key takeaways

Agent traffic needs more than uptime and status codes.
Wrap the protocol layer once to capture every call.
Alert on tool error rate, p95 latency, and completion rate.

Monitoring an MCP server is different from monitoring a typical web service. The traffic comes from AI agents, the errors hide inside successful responses, and the thing you care about is whether a task completed, not just whether the process is up.

Start with the protocol layer

Wrap your server once at the request/response boundary. Because every tool call flows through the same path, one wrapper captures the name, arguments, result, timing, and client for every call, with no per-tool code.

import { withTrackMCP } from "@trackmcp/sdk";
import { server } from "./mcp";

export default withTrackMCP(server, {
  apiKey: process.env.TRACKMCP_KEY,
});

One wrapper at the request/response boundary sees every call.

What to monitor

Tool-level error rate, separate from transport errors
Silent failures: isError responses inside a 200 OK
p95 latency per tool, not just the average
Completion rate: sessions that reach a useful result
Client mix and retries per session

Alert on the right things

Alert when a tool's error rate spikes, when p95 latency climbs, or when completion rate drops. These are the signals that a real user experience is degrading, and none of them show up in a plain uptime check.

See this on your own server

TrackMCP turns your MCP server's calls into adoption, workflows, and outcomes. One line to install.