Monitoring and Logging

MCP servers in production need the same observability as any other service: logging, metrics, and alerting. The challenge is that stdio servers run as child processes — their logs go to stderr (stdout is reserved for the MCP protocol), and they do not have built-in metric endpoints. The solution: write logs to stderr or to a file, and use a log aggregation service to collect them.

The metrics that matter: tool invocation count (which tools are used most?), latency per tool (which tools are slow?), error rate (which tools are failing?), and token efficiency (are tools returning too much data?). The last metric is unique to MCP — a tool that returns a 10,000-word response when a 100-word summary would suffice is wasting the client's context window. Monitor response sizes and optimize for conciseness.

1. 1. Log to stderr or File Stdio servers must never log to stdout — it corrupts the MCP protocol. Use console.error or a file-based logger. Include: tool name, parameters (sanitized), duration, success/failure, response size.
2. 2. Track Key Metrics Invocation count (usage patterns), latency (performance), error rate (reliability), response size (token efficiency). For SSE servers, use your standard APM. For stdio, parse log files or use a lightweight metrics library.
3. 3. Alert on Anomalies Error rate spike: tool is broken, investigate immediately. Latency spike: external dependency is slow. Response size spike: tool is returning unfiltered data. Zero invocations: tool might be misconfigured or poorly described.