# Monitor your MCP server
Source: https://speakeasy.com/mcp/monitoring-mcp-servers

MCP servers connect LLM agents to external services like databases, APIs, and internal tools. When something breaks, you need to know where the problem has occurred: Is your MCP server failing? Is the LLM making bad tool calls? Is there latency from your backend services or LLM processing?

API and web server monitoring involves tracking HTTP response times, error rates, HTTP call patterns, and other key metrics. Monitoring MCP setups requires more. The LLM interprets user intent and decides which tools to call. You need to monitor both the MCP server's performance and the LLM's tool usage patterns.

If you don't monitor your MCP server:

- **Tool call patterns stay hidden:** You can't optimize which tools to improve or remove.
- **Failures go undiagnosed:** Tool calls fail silently, and you don't know if bad parameters, backend issues, or LLM errors are at fault.
- **Latency problems compound:** Slow tools delay every agent response, but you need per-tool latency metrics to identify the specific tool causing the bottleneck.
- **Security breaches go undetected:** You risk overlooking unusual access patterns indicating prompt injection or data exfiltration.

This guide covers the metrics you should monitor and demonstrates how to set up monitoring for both self-hosted and distributed MCP servers.

## What to monitor in your MCP server

Your MCP server acts as the bridge between LLM agents and your backend services. The LLM requests tools, resources, or prompts from your MCP server, and your MCP server executes those requests.

![MCP server](/assets/mcp/monitoring-your-mcp-server/mcp-architecture.png)

Your monitoring should focus on the MCP server layer, collecting information about the tools that agents access, how the tools perform, and whether their usage patterns appear normal or suspicious.

### Tool call metadata

Every time an agent calls a tool, you need structured data about that invocation. This creates an audit trail showing the agent's actions, including when they were performed and whether they were successful.

Capture the following metadata:

- **Tool names and timestamps** to identify which tools were called and when. This allows you to correlate tool calls with coinciding user complaints or backend issues.
- **Input parameters (sanitized if sensitive)** to see what data the agent passed to the tool. When a tool fails, verify whether the agent sent malformed input, missing required fields, or invalid values.
- **Success or failure statuses** to track failure rates per tool, so you can identify unreliable tools that need optimization or better error handling.
- **Client or session identifiers** to link tool calls to specific users or sessions. Ideally, when a user reports an issue, you can trace their entire interaction history across multiple tool calls.
- **Error messages when tools fail** to gain insight into why the failure happened. Was it due to backend timeout, a database connection error, or an invalid API key? Error messages indicate where to begin debugging.

### Tool usage patterns

Beyond individual tool calls, you need to understand the bigger picture: which tools get used most, which ones fail together, and whether usage patterns change suddenly.

Capture the following usage patterns:

- **Tool call frequency per client** to establish a baseline of normal behavior. If a client that typically makes five calls per hour suddenly makes 60 calls, that signals a problem. The increase in calls could be caused by a runaway LLM agent or potentially by abuse.
- **Tool call sequences** to identify which tools are commonly used in workflows. When agents consistently chain Tool A with Tool B, the recurring pattern reveals an optimization opportunity. Learn more in the guide to [optimizing your MCP server](/mcp/tool-design).
- **Sudden spikes in specific tool usage** to catch anomalies. A tenfold increase in database query tools might indicate a prompt injection attack attempting data exfiltration or an agent stuck in a loop making the same call repeatedly.

For security-focused monitoring, such as authentication failures and unauthorized access attempts, read our guide to [securing your MCP server](/mcp/securing-mcp-servers).

### Tool performance metrics

Some tools respond within milliseconds; others take seconds. Some tools return compact JSON; others dump massive payloads. These differences matter because slow or bloated tools block the entire agent workflow.

Track the following performance metrics:

- **The latency per tool** to identify which tools slow down your entire system. Monitor the 50th, 95th, and 99th percentiles. For example, if a tool shows a 100-millisecond average latency but a five-second latency at the 99th percentile, you know that some requests block the agent for five seconds, degrading the user experience.
- **The response payload size per tool** to catch the tools returning excessive data. A tool that dumps 10KB when 1KB would suffice wastes tokens and clogs the LLM's context window. Large payloads also increase the network transfer time and processing overhead.

### Server-level metrics

Your MCP server's overall health determines whether it can handle the load that agents throw at it. High error rates, resource exhaustion, and rate limiting all degrade performance before they cause complete outages. Monitoring server-level metrics allows you to catch these capacity problems early, giving you time to scale or optimize resources before users experience failures.

Track the following server-level metrics:

- **The overall error rate across all tools** to detect infrastructure issues. For example, if error rates spiked across multiple tools simultaneously, the problem would likely be in shared infrastructure (such as database connections, authentication services, or network issues) rather than individual tool logic.
- **Request volumes and rate-limit hits** to understand if you need to scale capacity or if specific agents are making excessive calls. The number of rate limits hit indicates whether your infrastructure can't keep up with demand or a single client requires throttling.
- **Memory and CPU usage during high tool call volume** to identify resource constraints before they cause crashes. High memory usage during peak hours signals that you should add resources or optimize tool implementations that are leaking memory or consuming excessive CPU.

## How to monitor your MCP server

Your monitoring approach will vary based on how you deploy your MCP server. Remote servers offer you complete control over your infrastructure and tooling, whereas packaged servers require opt-in telemetry that respects user privacy.

### Remote servers

When you host your MCP server on your own infrastructure, you control the entire monitoring stack and can use standard production tooling.

#### Logging

Logging captures your tools' performance in real time. When a tool fails, logs provide information about the parameters passed, the external APIs called, and the location of the failure.

You can use FastMCP for logging as follows:

```python
import logging
from fastmcp import FastMCP, Context