# How to Test an MCP Server Before You Ship It

A successful MCP handshake proves connectivity, not production readiness. Test
discovery, authentication, tool schemas, tenant isolation, failure semantics,
and at least one real client workflow.

## Release checklist

1. Start from a cold client and verify the server card, transport, protocol
   version, documentation, and protected-resource metadata.
2. Treat tool schemas as public APIs: use specific names, when-to-use
   descriptions, typed inputs, bounded outputs, and accurate read/write
   annotations.
3. Test anonymous discovery separately from authenticated calls. Verify scopes,
   revocation, expiry, and organization boundaries.
4. Force missing credentials, wrong scopes, invalid arguments, provider
   timeouts, oversized results, and rate limits. Never convert failure into a
   successful empty result.
5. Use real storage to prove that two organizations cannot enumerate or infer
   one another's data.
6. Run a supported client through discovery, authentication, tool listing, and
   the intended tool call.
7. Preserve every escaped compatibility failure as regression coverage.

Record the client version, protocol version, server revision, scopes, and exact
result. A compatibility matrix should be executable evidence, not a marketing
table.

See EvalGate's [MCP integration guide](https://www.evalgate.com/docs/platform/mcp-integration)
and [machine-readable MCP contract](https://www.evalgate.com/mcp.md).