Define production readiness as evidence you can inspect

A server starts, lists its tools and answers a sample request. That is useful evidence of a working connection. Production readiness asks a larger question: can the intended user complete useful work, under the intended permissions, when dependencies and networks behave imperfectly?

You need a small set of observable answers. A long checklist with vague approvals can be easier to complete than a short checklist that asks someone to demonstrate an actual recovery.

Treat the launch review as an evidence review tied to a particular artifact and configuration. This keeps “ready” from becoming a label that survives after the system beneath it has changed.

Begin with one complete user journey

Choose a representative task that reaches a real consequence. For example, a support assistant finds an accessible issue, proposes a status change, applies the authorized transition and reports the result. Test the whole path with a new user account in the staging environment, not only with an administrator's long-lived session.

Record what the user needs before starting: account, role, integration connection and required resource. Make missing prerequisites visible. A dead end that asks the user to reconnect without explaining which connection failed is a launch issue even if the backend returned the technically correct error.

If the system offers a local installation path, run its documented commands from a clean environment using the published version. A README describing unreleased flags is not an onboarding path. Check public links while signed out, including package source, support and recovery documentation.

Review consequences before feature count

List the tools available to the launch cohort and identify the strongest consequence of each. Reading public documentation, reading private records, modifying a ticket and exporting files need different controls.

For each tool, name the principal, resource boundary, downstream credential and executor-side permission check. Verify at least one denied case. If the only tested user is an administrator, you have not established how the ordinary permission boundary behaves.

Review combinations as well as individual tools. A read capability plus an outbound-delivery capability may create a disclosure path even if each looks reasonable in isolation. Ask what stops retrieved content from changing recipients, widening the resource scope or reusing an approval for different arguments.

Use an evidence table rather than a confidence score

A launch record might contain the following application-specific checks:

Choose additional rows based on the service's actual consequences. Do not add a requirement solely to make the table look more comprehensive.

Google's SRE guidance on launch checklists emphasizes concrete, justified checks and ongoing curation. The table here applies that idea to an MCP service; it is not a universal certification scheme.

Test failures that change user decisions

A dependency timeout, expired credential and lost response are not interchangeable. The user needs to know whether to reconnect, retry, wait or avoid repeating an operation whose outcome is unknown.

Inject controlled failures in staging. Interrupt a read, interrupt a state-changing operation after it has been accepted, and revoke a test credential between preparation and execution. Check the actual downstream state and compare it with what the assistant reports.

Test large and empty results. Bound result size and make truncation visible. A user who sees only the first page should not be told that the list is complete. A no-results answer should not conceal a failed lookup.

Include cancellation and retry behavior. Confirm that stopping the interface has the intended effect on queued and running work. If cancellation is best-effort, communicate that limitation and provide a way to inspect the final outcome.

Match the release to its operating environment

Record the artifact, dependencies and configuration selected for production. Verify the intended listener, proxy rules, authentication domain, outbound destinations and resource limits. Avoid treating a staging success as evidence for a production configuration nobody has inspected.

Check certificate validity and the renewal path for public endpoints. Name an owner and an alert for expiry or renewal failure. Verify the public endpoint from outside the deployment network; an internal health check can remain green while users cannot establish a valid connection.

Ensure the deployment process can identify the running revision. A successful build job is not enough if an old artifact is still receiving traffic or a manual change was applied afterward. Keep the release record useful to the person who will investigate the next alert.

Make limits and costs visible before work begins

If a workflow can incur usage charges, show the applicable limits and the point at which the user commits to paid work. The public pricing page, checkout, documentation and enforced quotas should describe the same offer.

Do not display a trial, unlimited quota or automated protection merely because a design document mentions it. The production behavior needs to support the claim. A capability that depends on optional scanners or credentials should expose coverage and missing prerequisites in its result.

Define resource limits for callers as well. A single user should not be able to exhaust the worker pool or produce unbounded logs with one tool request. Test rejection behavior so limits fail clearly rather than leaving the interface indefinitely busy.

Decide how to release and how to stop

Choose an initial cohort whose workload and permissions you understand. Define the outcomes that would stop expansion: unauthorized effects, unresolved writes, a broken primary journey or a material increase in a known failure category. Aggregate latency alone cannot cover those risks.

Give the release an operator and a recovery decision. If reversing the application cannot reverse a database change, write a forward-repair plan and test it. Keep the original artifact and required backups through the support period established by your operational policy.

After rollout, complete the evidence record with production observations. Close the launch only when the intended artifact is serving the intended users and the agreed checks pass. That definition is deliberately concrete: another engineer should be able to inspect the same evidence and understand why the service was allowed to proceed.