How to Monitor an MCP Server in Production

To monitor an MCP server in production, check more than uptime. Verify that clients can discover the server, authenticate, see the expected catalog, call critical tools, recover from failures, and complete representative workflows.

The production monitoring model

• Availability: can the endpoint or process be reached?
• Discoverability: can a client retrieve the expected tools, resources, or prompts?
• Authorization: do valid clients authenticate and invalid clients fail safely?
• Execution: do critical tools return correct results with expected latency?
• Recovery: can agents understand errors, retry safely, and finish the task?
• Outcome: are real workflows producing the result users need?

1. Monitor the transport and protocol

A basic check should exercise the deployed transport rather than only pinging a port. Record response status, duration, protocol version, authorization behavior, and whether the expected discovery response is present. For remote HTTP deployments, include the full authentication and metadata-discovery path in a safe synthetic check.

2. Monitor the catalog

A server can be available while its advertised tools have changed, disappeared, or become unusable. Compare the observed catalog with a reviewed expected set. Track catalog changes as deploy events so an adoption or completion drop can be correlated with a tool rename, schema change, or removal.

3. Monitor tool behavior, not only server behavior

Rank tools by business criticality, not just volume. For each critical tool track call count, success, tool-level errors, validation errors, p50 and p95 latency, timeout rate, and retry rate. A single broken tool in a common workflow can be more damaging than a broad but low-volume warning.

4. Monitor agent workflows

A synthetic tool call proves that one input worked. A workflow check proves that a sequence works. Define representative paths such as search → fetch → summarize, or inspect → update → verify. Keep test data isolated and label synthetic traffic so it does not distort product analytics.

5. Separate paging alerts from investigation signals

• Page: endpoint unavailable, authorization outage, critical tool error spike, or sustained completion-rate failure.
• Warn: p95 regression, rising retries, catalog drift, or one client degrading.
• Investigate: unused tools, one-off validation errors, low-volume client changes, or a single slow request.

A useful MCP server SLO set

Set targets per environment and workflow. Example starting points are illustrative, not universal standards: 99.9% availability for the remote endpoint, 99% successful discovery for supported clients, 99% success for read-only critical tools, and a documented p95 target for each workflow-critical tool. The right thresholds depend on the dependency and user promise.

6. Create an incident runbook

• Confirm whether the issue is transport, authorization, catalog, tool, dependency, or outcome related.
• Break down the signal by client, tool, environment, version, and deployment time.
• Inspect the first failing event and the preceding successful event in the session.
• Check whether the agent retried, changed arguments, or abandoned the workflow.
• Mitigate with rollback, feature flag, rate limit, dependency fallback, or tool disablement.
• Record the fix and add a regression check for the failure mode.

7. Protect the monitoring data

Monitoring data can contain the same sensitive values as the tool call. Redact secrets and personal data before transmission, avoid logging bearer tokens, separate synthetic credentials from production credentials, and define who can inspect traces. Monitoring must not create a second path for data leakage.

Frequently asked questions