MCP Observability: What to Log and Measure in Production

If you only watch container CPU, you will ship green dashboards and broken agents.

The MCP observability stack

Protocol vs tool execution errors

The tools specification distinguishes (error handling):

1. Protocol errors — unknown tool, malformed request, server JSON-RPC errors
2. Tool execution errors — isError: true in the tool result (validation, business logic, upstream failures)

Clients SHOULD give tool execution errors to the model for self-correction. Track both rates separately.

What to measure first

1. Calls per tool — adoption and surprise spikes
2. Error rate per tool — broken schemas, missing secrets
3. Latency p50/p95 — slow tools poison agent loops
4. Auth failure rate — misconfig vs probing
5. Deploy version / artifact — correlate regressions

MCPLambda tool-usage analytics capture volume, errors, latency, and invocation history at the proxy (tool-execution time, not full LLM round-trip).

What to log

Servers MUST sanitize tool outputs (tools security). Clients SHOULD log tool usage for audit (same section).

Stdio caveat

On stdio transports, logs go to stderr, never stdout (stdio, build server).

Notifications and dynamic tools

If tools change at runtime and the server declared listChanged, expect notifications/tools/list_changed and ensure hosts refresh (tools, client best practices).

Debugging workflow

1. Client connects? → transport/auth (transports)
2. tools/list complete? → registration / crash on startup
3. Specific tool fails? → logs + upstream + isError body
4. Slow? → latency percentiles + dependency

Tools: MCP Inspector, debugging guide, debugging in production.

Alert ideas

• Tool error rate > threshold for N minutes
• Auth failures spike
• p95 latency SLO breach
• Deploy followed by error-rate delta

Worked scenario: Green CPU, red agents

Dashboards show healthy CPU and memory. Agents still fail. The missing signal is per-tool error rate: create_jira_issue returns isError: true because a project key changed. Infrastructure never blinked.

You add four golden signals: calls/tool, error rate/tool, p95 latency/tool, auth failure rate. You also log tool name + duration + success without payloads that contain secrets. After deploys, you watch a 45-minute burn-in window before calling the release done.

Checklist for this topic

• Track calls, errors, latency per tool—not only CPU
• Separate protocol errors from isError execution errors
• Log tool name/duration/status; never tokens
• Stdio logs go to stderr only
• Alert on error-rate and auth-failure spikes
• Correlate incidents with artifact version

Topic-specific failure modes

Related guides

Debugging · Rate limits · Testing

In practice: four golden signals

Ship dashboards on day one of production:

1. Calls / tool / minute
2. Error rate / tool (protocol vs isError)
3. p95 latency / tool
4. Auth failures / minute

Page a human when (2) or (4) spikes after a deploy. CPU graphs remain secondary.

Example alert policy

Tune numbers to your traffic; the important part is having tool-aware alerts at all.

Takeaways

For MCP Observability: What to Log and Measure in Production, remember three things:

1. Be specific to this problem — the worked scenario “Green CPU, red agents” is the failure mode you should design against, not a generic outage narrative.
2. Track per-tool volume, error rate, latency percentiles, and auth failures — not only container CPU.
3. Alert on empty tools/list, spike error rates, and p95 latency regressions that agents feel.

If you only remember one habit: if you cannot answer “which tool failed for which client,” you are not observability-complete for MCP.

Sources

• Tools — 2025-11-25
• Lifecycle — 2025-11-25
• MCP Inspector
• Debugging
• Client best practices
• Transports — stdio logging
• MCPLambda analytics

Next steps

Debugging MCP in production · Rate limits & cost