An administrator configures a local MCP server that uses the stdio transport. Which party starts the server process?
Select an answer to reveal the explanation.
Short Explanation
With stdio, you can think of the client as the parent and the server as the child process it spawns. They talk through stdin and stdout, like passing notes through a door. No sockets, no daemons, no boot-time magic.
Full Explanation
The stdio transport specification opens with the rule that the client launches the MCP server as a subprocess. The two ends communicate over the subprocess's standard streams: the server reads newline-delimited JSON-RPC messages from stdin and writes JSON-RPC messages to stdout, while stderr may carry logging. The client also controls the lifecycle, initiating shutdown by closing the server's input stream, waiting for exit, and forcibly terminating if necessary, and it SHOULD restart the server if the process exits unexpectedly. Describing the server as a daemon with a listening socket describes a network deployment such as Streamable HTTP, where the server is an independent process; stdio has no listening socket. Having the operating system start the server at boot misplaces lifecycle control, and server/discover is a capability and version discovery request, not a way to locate processes on a machine. The model selects tools from definitions the host already holds; it does not spawn processes, and the server must be running before its tools can be listed. Exam caveat: because the protocol is stateless, a restarted stdio server holds no subscriptions, so clients must re-send subscriptions/listen after a restart. Operational check: inspect the process tree and confirm the stdio server runs as a child of the client process, with stdout carrying only MCP messages.