AppMatic Tech runs a 12-point deployment checklist on every MCP server before production, covering secrets management, token refresh under load, per-user access control, schema validation, LLM routing accuracy, P95 latency, connection pools, API rate limits, audit logging, and zero-downtime credential rotation. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
AppMatic Tech runs a 12-point deployment checklist before every MCP server goes into production. The checks below are not theoretical. Each one exists because a specific failure mode appears when it is skipped. The checklist takes two to three hours to work through on a completed build and prevents the category of production incident that requires a late-night rollback.
What does the MCP deployment checklist assume?
This checklist assumes the MCP server implementation is functionally complete: resource handlers are implemented, the data access layer is connected to the production data source, and the LLM client can reach the server endpoint. These are go-live checks, not implementation checks.
Which authentication checks must pass before MCP go-live?
1. Service credentials are stored in environment variables or a secrets manager, not in source code.
Run a search for hardcoded credentials before deployment. This includes API keys, database passwords, and OAuth client secrets. A credential in source code is a credential in version history, which means it remains exposed after the code is updated.
2. Token refresh works under concurrent load.
For MCP servers using OAuth 2.0 to connect to downstream APIs, simulate the access token expiry under concurrent request load and confirm the token refresh mechanism handles it without returning authentication errors to in-flight requests. Token refresh failures under concurrent load are one of the most common post-launch incidents on CRM and ERP integrations.
3. Per-user access control is enforced at the data layer, not at the application layer.
For multi-tenant deployments, confirm that a request authenticated as User A cannot retrieve data belonging to User B by modifying query parameters. This test should be run explicitly, not assumed to pass because the code looks correct.
Which schema and input validation checks must pass?
4. All resource parameters are validated before reaching the data access layer.
Send malformed requests to each resource handler and confirm the server returns structured error responses rather than unhandled exceptions. Test with wrong data types, missing required fields, out-of-range values, and oversized strings. The server should handle all of these gracefully without exposing stack traces or database error messages in the response.
5. The LLM routes queries to the correct resources under realistic user input.
Run the actual LLM client through 20 to 30 realistic user queries and verify that each query routes to the intended resource. Mis-routing happens when resource descriptions are too similar or too vague. Correct any description ambiguity discovered during this test before go-live. This check cannot be replaced by unit tests because it tests the LLM's routing behaviour, not the server's handler logic.
6. Edge case query parameters return correct results, not empty sets or errors.
Test each resource with filter parameters at boundary conditions: date ranges of zero duration, filter values that match zero records, filter values that match the maximum expected record count. Empty result sets should return a valid empty response, not a null reference exception.
Which performance and load checks must pass?
7. Response time at P95 is within the acceptable latency budget under expected concurrent load.
Run a load test at the expected production peak request volume and measure P95 response time. For conversational LLM features, 800ms is a reasonable upper bound for the MCP server's contribution to end-to-end latency. For background analytical queries, higher latency is acceptable. Define the target before the test, not after.
8. The connection pool to the data source does not exhaust under concurrent load.
Configure the data source connection pool to a realistic size for the expected concurrency and confirm the server handles request queuing correctly when all connections are in use. A server that throws connection pool exhaustion errors under load needs pool sizing adjustment or a queuing layer before launch.
9. Rate limits on external APIs are not reached at expected load.
For CRM and ERP integrations, calculate the expected request volume across all concurrent users and confirm it is within the external API's rate limit with headroom for traffic spikes. If the expected volume approaches the rate limit, caching needs to be added before launch.
Which audit logging checks must pass?
10. Every resource query is logged with user identity, timestamp, parameters, and result count.
Verify that the audit log produces a complete record for each request and that the log is written to a separate store that cannot be modified by the MCP server's own credentials. Run a sample query and confirm the log entry appears within the expected write latency.
11. Error responses are logged with enough context to diagnose without reproducing the error.
Trigger each error type the server can produce and confirm the error log includes the resource name, the parameters that caused the error, and the error type. Logs that only record "error occurred" require reproduction of production errors to diagnose, which is time-consuming and sometimes impossible.
Can MCP credentials be rotated without downtime?
12. Service credentials can be rotated without downtime.
Update the service credential in the secrets manager and confirm the MCP server picks up the new credential within the configured reload interval without failing in-flight requests. This test validates that the secret rotation mechanism works before the first time it is needed in a real credential rotation or incident response scenario.
When is an MCP server ready for production?
A build that passes all 12 checks is ready for production deployment. AppMatic Tech considers a build complete when the deployment checklist passes, not when the implementation is functionally complete. The distinction matters: functional completeness means the server works correctly under expected conditions, deployment readiness means it handles the unexpected conditions that occur in production.
AppMatic Tech includes the deployment checklist as a standard deliverable on all MCP server builds. Every client receives the completed checklist with test results before handover. For the security practices that inform items 1 through 3 on this list, see MCP Server Security: Best Practices for Enterprise Deployments.
For a delivered example, see how AppMatic Tech built and deployed the ConstructionMCP platform. Full engagement details are on the MCP Server Development service page. Contact AppMatic Tech at contact@appmatictech.com.
Frequently Asked Questions
- What should be checked before an MCP server goes live?
- AppMatic Tech verifies 12 items: credentials held in a secrets manager, token refresh under concurrent load, per-user access control at the data layer, schema validation of every parameter, correct LLM routing across 20 to 30 realistic queries, edge-case parameters, P95 latency under peak load, connection pool sizing, external API rate limits, complete audit logs, diagnosable error logs, and credential rotation without downtime.
- What is an acceptable latency for an MCP server?
- For conversational LLM features, AppMatic Tech treats 800ms at P95 as a reasonable upper bound for the MCP server's share of end-to-end latency, measured under the expected production peak. Background analytical queries can tolerate more. The target is defined before the load test, not after.
- How do you test that an LLM routes MCP queries correctly?
- AppMatic Tech runs the actual LLM client through 20 to 30 realistic user queries and checks that each one reaches the intended resource. Mis-routing comes from resource descriptions that are vague or too similar to each other, and it cannot be caught by unit tests because it tests the model's routing, not the handler code.
- Where should MCP audit logs be stored?
- In a separate, append-only store that the MCP server's own credentials cannot modify. AppMatic Tech logs every query with user identity, timestamp, parameters, and result count, and confirms during go-live checks that each sample query produces a complete log entry within the expected write latency.
- How long does the MCP deployment checklist take?
- The 12-point checklist takes AppMatic Tech two to three hours on a completed build. AppMatic Tech treats a build as complete only when the checklist passes, and every client receives the completed checklist with test results at handover.