Part 3: Testing, Deploying, and Lessons Learned

The final part of a three-part series on building our first MCP server for healthcare interoperability. Where We Left Off Part 1 covered the why — the problem space, the choice of MCP, and the architectural decisions. Part 2 covered the how — the indexer, URI scheme, tool handlers, and transport layer. This final post covers the operational reality: how we test an MCP server, the developer workflow, deploying to real AI clients, and the honest retrospective on what worked and what we'd change. Testing an MCP Server: It's Weirder Than You Think Testing a regular API is well-understood: spin up a server, send requests, assert on responses. Testing an MCP server adds a twist: your primary consumer is an AI, and you can't write assertions about AI behavior. We developed a three-layer testing strategy: Layer 1: Unit Tests for Handlers Each handler is a pure function: it takes a Pydantic model and returns a dict. This makes unit testing straightforward. The trick is the database. Our handler