MCP server SLA

SLI, SLO, and SLA: the three-tier framework

These three terms are often used interchangeably but represent distinct layers of the availability framework:

The gap between SLO and SLA is intentional: your SLO should be more aggressive than your SLA so that when the SLO fires (internal alert), you still have room to recover before breaching the SLA (contractual trigger). If SLO = SLA, every internal alert is also a credit event — engineering has no runway.

What to measure: the MCP server SLI

The SLI for an MCP server should reflect what your customers actually depend on: the ability to successfully initiate an MCP session and call tools. This means the probe must do more than check if a TCP port is open.

#!/bin/bash
# mcp-sli-probe.sh — measure one probe interval for SLI calculation

SERVER_URL="${1:-https://mcp-search.internal/mcp}"
TIMEOUT_SECS=5
START_MS=$(($(date +%s%N)/1000000))

# Send real MCP initialize request
RESPONSE=$(curl \
    --silent \
    --max-time "$TIMEOUT_SECS" \
    --write-out "\n%{http_code}\n%{time_total}" \
    --request POST "$SERVER_URL" \
    --header "Content-Type: application/json" \
    --data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","clientInfo":{"name":"sli-probe","version":"1.0"}}}')

HTTP_CODE=$(echo "$RESPONSE" | tail -2 | head -1)
ELAPSED_MS=$(echo "$RESPONSE" | tail -1 | awk '{printf "%d", $1*1000}')
BODY=$(echo "$RESPONSE" | head -1)

# SLI = "good" if:
# 1. HTTP 200
# 2. Response contains protocolVersion (valid MCP response)
# 3. Elapsed time < SLI threshold (5000ms)
if [ "$HTTP_CODE" = "200" ] \
    && echo "$BODY" | grep -q '"protocolVersion"' \
    && [ "$ELAPSED_MS" -lt 5000 ]; then
    echo "GOOD latency=${ELAPSED_MS}ms"
    exit 0
else
    echo "BAD http_code=$HTTP_CODE latency=${ELAPSED_MS}ms"
    exit 1
fi

Log each probe result (timestamp, good/bad, latency) to calculate the availability percentage at the end of each calendar month.

Latency SLI: beyond binary availability

A server that responds to every initialize in 4,900 ms is technically "up" but is causing meaningful latency in agent pipelines. Consider adding a latency SLI alongside the availability SLI:

# Latency SLI (separate from availability SLI)
# "good" = p99 response time for tools/call < 500ms over the measurement window

# Measured via AliveMCP response-time histogram:
# curl -H "Authorization: Bearer $TOKEN" \
#   "https://alivemcp.com/api/v1/servers/mcp-search/metrics?period=2026-05" \
#   | jq '.response_time_p99_ms'

Availability percentage and downtime budget

Availability percentage = (total probe intervals − failed intervals) / total probe intervals × 100. A probe interval that times out counts as failed. A probe interval that returns a 5xx error counts as failed. A probe interval that returns a 200 with a malformed (non-MCP) response counts as failed.

Choose the SLA tier based on your current measured performance with headroom. If your MCP server historically achieves 99.97% availability (measured over the last 90 days), committing to 99.9% gives you a 7× safety margin on the failure budget. Committing to 99.99% leaves you with a 3× margin — acceptable, but requiring rigorous on-call coverage to recover within 4 minutes of failure.

What counts as downtime

Define downtime precisely in the SLA. Ambiguity here is where enterprise procurement disputes start. A robust definition for MCP servers:

# SLA downtime definition (include verbatim in customer agreements)

"Downtime" means any period during which AliveMCP's external monitoring probe
is unable to successfully complete a Model Context Protocol (MCP) initialize
handshake with the Service endpoint within 5,000 milliseconds. A period of
downtime begins when three consecutive probe intervals fail and ends when three
consecutive probe intervals succeed.

Excluded from downtime calculation:
- Scheduled maintenance windows (notified ≥72 hours in advance via status page)
- Probe failures caused by customer-side network issues or client misconfigurations
- Periods of force majeure (as defined in the Master Services Agreement)
- The first 5 minutes of any incident (allowing for transient network noise)

The "three consecutive failures to start, three consecutive successes to end" rule prevents a single probe timeout (which could be a transient network blip) from triggering an SLA event. With 60-second probe intervals, this means a genuine outage is detected within 3 minutes of starting.

Credit schedule design

Credit schedules should scale with severity — a minor SLA miss (99.88% vs 99.9% target) earns a smaller credit than a catastrophic month (95% availability). Standard enterprise SaaS credit schedules adapted for MCP servers:

# Credit schedule (include in customer SLA addendum)

Monthly Availability    Credit (% of monthly fee)
─────────────────────   ──────────────────────────
≥ 99.9%                 No credit (within SLA)
99.0% – 99.9%           25%
98.0% – 99.0%           50%
< 98.0%                 100%

Credit for individual incidents:
─────────────────────────────────
Incident duration  < 30 min:   No credit
Incident duration 30–60 min:   10% of monthly fee
Incident duration 60–120 min:  25% of monthly fee
Incident duration > 120 min:   50% of monthly fee

(Credits from monthly availability and individual incidents do not stack.
 The higher of the two applies for any given month.)

Cap total credits at 100% of monthly fee. Enterprise customers sometimes negotiate for credits that exceed the monthly fee ("consequential damages"), but this is standard liability waiver territory — your legal team should handle this via limitation of liability clauses in the Master Services Agreement, not in the SLA addendum.

Monthly SLA report format

Enterprise procurement teams require monthly SLA reports as evidence for their own SOC 2 audits and vendor management processes. A complete MCP server SLA report contains:

• Reporting period: calendar month start and end date (UTC)
• Availability percentage: calculated from external probe data (not self-reported)
• Total probe intervals: number of probe intervals in the period
• Failed intervals: count and percentage
• SLA commitment met: yes/no
• Credit owed: dollar amount if applicable, or $0 if SLA met
• Incident list: each incident with start time, end time, duration, and root cause classification
• Response time percentiles: p50, p95, p99 for the period
• Uptime chart: 30-day availability timeline, 1-day resolution
• Maintenance windows: list of scheduled windows and whether they were used

# Generate SLA report from AliveMCP API (Team/Enterprise tier)
curl -H "Authorization: Bearer $ALIVEMCP_TOKEN" \
    "https://alivemcp.com/api/v1/servers/mcp-search/sla-report?month=2026-05" \
    --output "sla-report-mcp-search-2026-05.pdf"

# Or JSON for programmatic use
curl -H "Authorization: Bearer $ALIVEMCP_TOKEN" \
    "https://alivemcp.com/api/v1/servers/mcp-search/sla-report?month=2026-05&format=json" \
    | jq '{
        period: .period,
        availability_pct: .availability_pct,
        sla_target_pct: .sla_target_pct,
        sla_met: .sla_met,
        credit_owed_usd: .credit_owed_usd,
        incidents: .incidents | length,
        p99_response_ms: .response_time_p99_ms
    }'

Measuring SLA from external probes vs internal metrics

Self-reported availability (measuring from your own server's metrics) has a fundamental problem: it only counts requests the server actually received and processed. It cannot measure downtime caused by:

• Network failures between the load balancer and the internet
• DNS resolution failures
• TLS certificate expiry at the edge
• Infrastructure-level failures that prevent requests from reaching the server

From the customer's perspective, all of these are downtime — their agent couldn't connect. From your internal metrics, they appear as zero requests (not as errors). The gap between "external availability" and "server-side request success rate" is often 0.05–0.1% over a year — enough to push a 99.95% self-reported number below 99.9% when measured externally.

Enterprise SLA agreements should always specify that availability is measured by an independent external probe, not by the server's own metrics. AliveMCP's probe is the canonical source for this measurement in AliveMCP Team and Enterprise accounts — the monthly report timestamps map directly to the data your customers' auditors want.

Further reading

• MCP server SLO — internal objectives, error budgets, and burn rate alerts
• MCP server SOC 2 — Availability criterion and audit evidence
• Enterprise MCP deployment — HA, blue-green, and change management
• MCP server incident response — detection, triage, and post-mortem
• MCP server uptime monitoring — probe types, intervals, and alert tiers
• MCP server status page — public and private status communication
• AliveMCP — continuous protocol monitoring for MCP servers