Skip to main content
MCP monitoring shows whether your server is available, fast, correct, and secure. MCP logging records the events that explain what happened during a request. A production MCP server needs both. Metrics reveal a problem. Structured logs and traces help you find its cause.

​
What should you monitor?

Monitor the complete path from the MCP client to the upstream system:
Track results by tool name and server version. A healthy overall average can hide one slow or failing tool.

​
Use structured logs

Write logs as structured fields instead of long free-form strings.
Useful fields include:
  • Timestamp and severity
  • Request, session, and trace identifiers
  • MCP method and capability name
  • Tool, resource, or prompt name
  • Authenticated principal or anonymized tenant identifier
  • Server and protocol version
  • Duration, result size, and outcome
  • Safe error category and upstream status
Do not record access tokens, API keys, authorization headers, prompt contents, personal data, or complete tool arguments by default.

​
Follow MCP logging rules

The MCP specification lets a server declare the logging capability and send structured notifications/message events. A client can request a minimum severity with logging/setLevel. For a local stdio server, reserve stdout for protocol messages. Send operational logs to stderr. Writing ordinary logs to stdout can corrupt the JSON-RPC stream. Protocol logs are useful to the connected client. They do not replace your server-side observability pipeline, audit log, or infrastructure metrics.

​
Add distributed tracing

Create a trace at the MCP request boundary and a span for each important step:
Propagate a correlation identifier to the upstream API when possible. This connects a failed tool call to the corresponding API, database, or queue event. Keep internal trace identifiers out of model-visible error messages unless they are safe support references.

​
Build useful dashboards

Start with four dashboards:
  1. Service health: availability, request rate, latency, and error rate.
  2. Tool usage: calls, success rate, latency, and result size by tool.
  3. Dependencies: upstream API latency, status codes, retries, and rate limits.
  4. Security: authentication failures, denied operations, unusual call volume, and destructive actions.
Use percentiles for latency. Averages can hide a poor experience for a smaller group of users.

​
Alert on user impact

Good alerts describe an actionable failure:
  • Initialization failures exceed the normal baseline.
  • A tool’s error rate remains above its threshold.
  • p95 latency breaches the service objective.
  • Upstream 429 or 5xx responses rise sharply.
  • Authorization failures or destructive calls increase unexpectedly.
  • No requests or heartbeats arrive when traffic is expected.
Add a runbook link, affected service, severity, and owner to every alert. Avoid paging on isolated errors that recover automatically.

​
Separate operational logs from audit logs

Operational logs help you debug reliability. Audit logs answer who performed a sensitive action, what changed, and whether it was allowed. For a write or destructive tool, an audit event should include:
  • The authenticated actor
  • The tool and target object
  • The authorization decision
  • A timestamp and correlation ID
  • The outcome and safe change summary
Protect audit logs from modification and restrict access to them.

​
Monitor a 0mcp server

0mcp provides activity logs and usage analytics for hosted MCP servers created from OpenAPI, Swagger, direct REST API, or GraphQL sources. Use Analytics to review usage patterns and Logs to investigate individual calls. When you publish a new version, compare errors and latency with the previous version and use rollback if necessary.

​
Production checklist

  • Structured logs use stable field names
  • stdout is reserved for stdio protocol messages
  • Secrets and sensitive payloads are redacted
  • Metrics are segmented by tool and version
  • Traces cover upstream dependencies
  • Dashboards show availability, latency, errors, and saturation
  • Alerts have thresholds, owners, and runbooks
  • Sensitive actions create protected audit events
  • Retention and access policies match your compliance needs

​
Key takeaway

Monitor MCP as an end-to-end system: protocol health, capability usage, upstream dependencies, security decisions, and user-visible outcomes.