Production and Ecosystem
“It works” is the halfway point
Section titled ““It works” is the halfway point”By now you can build a server that lists tools, serves resources, speaks both transports, and asks the user for input. That server works. It is not yet good.
Two audiences decide whether an MCP server is good, and neither of them is you:
- The model. It reads your tool names and descriptions cold, with no README, and decides in one pass which tool to call and how. A tool that a human can figure out in ten minutes is a tool the model will misuse in ten milliseconds.
- The operator. Someone deploys your server behind a load balancer, watches it at 3 a.m., and upgrades it without breaking the clients already connected. If the server hides state in a process, logs to stdout, or ships breaking tool changes silently, that person pages you.
This module is about serving both audiences, and then about the ecosystem your server lives in: how people find it, install it, and what the protocol is growing into.
flowchart LR a["Works locally"] --> b["Tools a model uses well"] b --> c["Tested and debuggable"] c --> d["Deployed stateless behind HTTPS"] d --> e["Published and discoverable"] e --> f["Extensions: Tasks, Apps"]
What this module covers
Section titled “What this module covers”| Lesson | Question it answers |
|---|---|
| Designing Tools for Agents | Why does the model keep picking the wrong tool, and how do I fix the definition instead of the prompt? |
| Testing and Debugging | How do I poke a server without an LLM in the loop, write tests that run in CI, and read the wire when it breaks? |
| Deploying Remote Servers | What does a stateless Streamable HTTP server need from its proxy, its runtime, and its operator? |
| Publishing and the MCP Registry | How do people install my server with one line, and how do I list it in the official registry? |
| Extensions and the Road Ahead | What are Tasks and MCP Apps, what is deprecated, and how does the spec evolve? |
The three habits this module installs
Section titled “The three habits this module installs”Design for the reader that is a model. Every tool description is a prompt. Every parameter name is a hint. Every error message is a chance for the model to self-correct instead of giving up. You will learn to write those three things deliberately.
Trust the wire, not the SDK. When something goes wrong, the JSON-RPC messages on the wire are the ground truth. The Inspector shows them to you; in-process tests let you assert on them. An SDK abstraction that you cannot see through is a liability at 3 a.m.
Stay stateless, stay boring. Protocol version 2026-07-28 removed sessions on purpose. A server that keeps its promise of “every request stands alone” scales horizontally for free, survives restarts, and needs no sticky load balancing. Every deployment decision in this module follows from that one property.