Every piece you built — messages, schemas, dispatch, tools, guards, resources — exists to be launched by a real client and used for real.
1stdio: The Simplest Real Transport
For a server meant to run locally alongside the client, stdio (standard input and output) is the natural transport: the client launches your server as a subprocess and exchanges JSON-RPC messages over its stdin and stdout, with no ports, no network configuration, and no separate authentication layer to build — the process boundary and the user's own permissions are the trust boundary.
2The Config File Is the Only Glue Needed
Registering a server is just naming the command and arguments that start it. There's no custom integration code on the client side — this is the entire payoff of building to a shared protocol from Module 1 onward: any compliant client can launch and talk to your server the same way, without you writing client-specific glue.
3Step-by-Step Breakdown
Connecting DevAssist to a Real Client. Everything you built runs as a plain local process. To connect it to Claude Desktop, you register it in a config file naming the command that starts your server — Claude Desktop launches it and talks to it over stdio, sending and receiving the exact JSON-RPC messages you built by hand in Module 1.
Why does Claude Desktop launch your MCP server as a local subprocess and talk to it over stdio, rather than connecting to it over the network like a typical web API?
- →stdio is simple, requires no network configuration or open ports, and fits a server meant to run locally with the same trust boundary and file access as the user launching it.
- →MCP servers are technically incapable of ever running over a network connection.
DevAssist, Complete. You built a real MCP server from nothing: JSON-RPC messages by hand, real tool schemas, a real dispatch table, file and task tools with real state, a live model choosing and calling those tools, a hardened path-traversal guard, and real resources alongside them. This is the actual mechanism behind every 'AI assistant with tools' product you've used — not a black box anymore.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Log Startup Failures Somewhere Visible
If your server fails to launch (missing dependency, wrong path in config), write a clear error to stderr so a user debugging a broken connection has an actual signal to work from.
import sys; sys.stderr.write("missing dependency: mcp\n")SEO Implications
- 1
Target 'connect MCP server to Claude Desktop' and 'MCP stdio transport explained' separately
Developers shipping their first server search for the concrete setup step and the underlying transport concept independently.
Best Practices
Test Your Server With a Minimal Manual JSON-RPC Exchange Before Connecting a Real Client
Sending a hand-built tools/list request and checking the response, the same way you built requests in Module 1, catches wiring bugs before they're obscured by a client's own error handling.
Frequent Bugs
Printing debug output to stdout instead of stderr in a stdio-transport server.
stdout is the actual JSON-RPC channel — any stray print() call corrupts the message stream the client is trying to parse. Debug output must go to stderr instead.
Real-World Examples
Local Dev Tool Servers
Filesystem, git, and task-tracker MCP servers used inside IDEs and desktop AI assistants almost universally use stdio, since they run on the same machine as the client and need no network exposure at all.
command: "node", args: ["server.js"]