If you've built more than one MCP server, you've probably noticed a pattern: the first version takes an afternoon, and the second version — the one that actually has to survive real traffic, real auth flows, and real agent behavior — takes weeks. That gap is where most of the "MCP is overhyped" complaints come from. It's not that MCP is bad. It's that most public examples stop exactly where production work begins. This post pulls together the lessons from two things we've built recently: a full minimal production-ready MCP server walkthrough covering auth, sessions, and error recovery, and a testing pyramid for MCP servers covering how to actually verify tool behavior instead of just eyeballing it. Rather than repeat either in detail, this is the condensed checklist — the thing you'd actually tape to the wall before a release.
Tutorials show you one path through one server. A checklist works differently: it's a list of things that will bite you regardless of which framework, transport, or model you're using, because they're structural, not implementation details. If you can check every box below, you're in materially better shape than 90% of the MCP servers currently sitting in public repos.
This is the section most public MCP examples skip entirely, which is a shame because it's also the highest-leverage one.
| Layer | What it checks | Typical tooling |
|---|---|---|
| Unit | Tool logic in isolation, no protocol involved | Standard test framework for your language |
| Contract | Tool schemas match what the server actually returns | Schema validation against real responses |
| Integration | Server behaves correctly over the actual MCP transport | A real client hitting a real running server |
| Agent-eval | The agent , given the tool, produces correct outcomes | Scripted agent runs with known tasks and expected results |
The last layer is the one people underrate. A tool can pass every unit and integration test and still be unusable in practice because the model consistently misuses it — wrong argument shapes, wrong assumptions about return values, wrong retry behavior. You find that out by actually running an agent against the tool with realistic tasks, not by testing the tool in a vacuum.
The realistic way to use this list isn't as an aspirational document — it's as a gate. Before a server goes anywhere near production traffic, someone (even just you, alone, with coffee) should go through each section and either check the box or write down why it's explicitly out of scope for this release. "We're not handling reconnect gracefully yet, and here's the ticket" is a fine thing to ship with. Silently not knowing is not.
If you want this in a form you can actually use instead of re-deriving it from blog posts every time, we packaged the checklist above along with a minimal working server template (the same one from the walkthrough post, stripped down to the essentials) and the agent-eval test scaffolding as a single pack: the MCP Production Checklist & Toolkit. It's meant to save you the week of scaffolding work, not replace the thinking — you still have to decide what your worst-case action is. None of this is exotic engineering. It's the same discipline you'd apply to any service that takes untrusted input and takes real actions — auth, scoping, timeouts, structured errors, and tests that check outcomes, not just responses. The reason it feels new is that MCP made it very easy to skip straight to "it works in my terminal" and call that done. It's a good starting point. It's not a production system yet, and the gap between the two is exactly the six sections above.
Written with AI assistance and reviewed for accuracy.