MCP Server SLOs: What to Measure Beyond Uptime

An MCP server SLO should measure whether supported clients can complete important work, not only whether an endpoint responds. A useful starting model covers availability, discovery, critical tool success, tail latency, authorization, and workflow completion, with each objective tied to an owner and an action.

The six SLO layers

• Availability: the remote endpoint or process is reachable.
• Discovery: clients can retrieve the expected catalog and metadata.
• Authorization: supported identities can authenticate and unauthorized actions are denied.
• Tool success: critical tools return an acceptable result.
• Latency: critical tools and workflows stay within a useful response budget.
• Outcome: representative workflows reach their defined terminal result.

Define the numerator and denominator

Every SLO needs a precise eligible-event definition. For example, critical-tool success can be successful tool results divided by eligible tool calls, excluding intentionally rejected requests only when that exclusion is documented. Workflow completion can be completed workflows divided by started workflows, with synthetic traffic labeled separately.

Use p95 for the tail

Average latency hides the calls that agents time out on. Track p50 for the typical call and p95 for the tail, per critical tool and, where possible, per workflow. A 300 millisecond tool called five times can create a very different user experience from one called once.

Error budgets for MCP

An error budget converts a reliability target into a release and investigation policy. If a critical workflow burns its budget, pause risky catalog or dependency changes, investigate the first failing step, and prioritize reliability work. Keep low-value experimental tools from dominating the budget for a critical workflow.

Alert on a user-visible condition

• Page when the endpoint is unavailable or a critical workflow cannot complete.
• Warn when p95 latency, retries, or tool errors trend beyond the baseline.
• Investigate catalog drift, unused tools, or isolated low-volume failures without paging.
• Break every alert down by client, tool, environment, version, and deployment.

A starting dashboard

• Availability and authorization success over time.
• Discovery success and catalog changes by client.
• Critical tool success, p50, p95, and timeout rate.
• Workflow starts, completions, failures, and retries.
• Budget consumed, active incidents, and recent deployments.

Frequently asked questions