MCP Server Production Readiness Checklist

An MCP server is production-ready when it can be discovered, authenticated, operated, monitored, and safely changed without relying on a developer watching every agent session. Use this checklist before exposing it to production users or state-changing workflows.

Architecture and deployment

• Choose the transport and protocol version deliberately; document supported clients and fallbacks.
• Separate development, staging, and production servers and credentials.
• Make deployments reproducible and pin runtime, SDK, and dependency versions.
• Define timeouts, concurrency limits, rate limits, and dependency budgets.
• Plan horizontal scaling and confirm whether application state is safe to share or must be externalized.
• Provide a rollback path for server code, tool catalog, and authorization configuration.

Tool design and catalog quality

• Use clear, distinct, action-oriented tool names.
• Describe when a tool should and should not be used.
• Make input schemas explicit and tolerant of common model-generated shapes where safe.
• Return actionable errors that tell the agent what to change.
• Separate read-only, write, destructive, and administrative capabilities.
• Test tool selection, not only handler correctness.
• Track unused tools and remove or improve tools that add catalog noise.

Security and authorization

• Use HTTPS for remote authorization flows and validate redirect URIs exactly.
• Validate token audience and issuer; never accept or pass through tokens intended for another resource.
• Use least-privilege scopes and separate identities for users, agents, and service accounts.
• Protect authorization code flows with PKCE and state validation.
• Defend outbound requests against SSRF and restrict reachable hosts where possible.
• Treat tool descriptions, resources, and external content as untrusted input.
• Review state-changing tools for confirmation, idempotency, and rollback behavior.

Observability and operations

• Capture client, tool, method, session or trace, duration, outcome, and environment.
• Measure tool-level errors separately from transport errors.
• Track p50 and p95 latency, retries, timeouts, and incomplete workflows.
• Define alerts for critical tools and representative workflows.
• Make telemetry fail-open so analytics outages do not block tool execution.
• Redact secrets and personal data locally before telemetry leaves the server.
• Create an incident runbook and test it with a synthetic failure.

Testing and release gates

• Unit-test handlers, schemas, authorization checks, and error states.
• Run integration tests with the supported MCP clients.
• Test malformed arguments, expired tokens, missing scopes, timeouts, retries, and dependency failures.
• Run a representative multi-tool workflow against staging.
• Compare the tool catalog and schema diff during release review.
• Record the protocol, SDK, client, and server versions in test output.

Go-live decision

Do not treat this checklist as a binary certification. Record each item as pass, partial, not applicable, or blocked, and assign an owner. A server with no write tools may have a different risk profile from one that can send messages, mutate records, deploy infrastructure, or access sensitive data.

Frequently asked questions