MCP in Practice — Part 6: Your MCP Server Worked Locally. What Changes in Production?
This article explores the journey of an MCP server from a local prototype to a production system, highlighting the challenges and changes that occur along the way.
Why it matters
Understanding the evolution of an MCP server from a local prototype to a production system is crucial for developers working with distributed systems and microservices.
Key Points
- 1The MCP server initially runs locally as a subprocess of the host application, using stdio transport
- 2When a second developer wants to use the server, the deployment model breaks as each user needs their own copy
- 3The server is then moved to a shared remote server, using Streamable HTTP as the transport instead of stdio
- 4The network crossing is the most important change, as the server is now accessible to anyone who can reach the URL
Details
The article follows the journey of an MCP (Microservices Communication Protocol) server, the TechNova order assistant, as it grows from a local prototype to a production system. Initially, the server runs on the developer's laptop, with Claude Desktop launching it as a subprocess and communicating over stdio. This works well for a single user, but when a second developer wants to use the server, the deployment model breaks, as each user needs their own copy of the server. To address this, the server is moved to a shared remote server, exposing a single HTTP endpoint and accepting JSON-RPC messages as HTTP POST requests. This network crossing is the most significant change, as the server is now accessible to anyone who can reach the URL, rather than just the process that launched it.
No comments yet
Be the first to comment