A green suite, a dead server: the MCP bug that lives four lines above your tests

A test that imports a handler and calls it never learns whether the handler was reachable. The story-cli suite covered JSON-RPC parsing and serialization, tool registration, and every tool handler, and all of it passed ^[2]; the protocol module was written as pure functions and described as fully tested ^[14]. The defect sat in the CLI entry file, above everything the suite could see: `await run(process.argv)`, then `process.exit(exitCode)` ^[5]. Because `startMcpServer()` registers stdin listeners and returns instead of blocking, `run()` resolved with 0 and the exit fired before readline read a byte ^[6].

The detail that should bother anyone who owns a CI config: under `spawnSync`, the process reported exit code 0 with nothing on stdout and nothing on stderr ^[4]. So an integration test that spawns the built binary and asserts a clean exit passes as well. The only check that separates a server from a process that agreed to start and then quit is one that writes a request in and requires bytes back. Absent that, the author debugged by hand and spent the first stretch suspecting his own shell, trying printf, a file redirect, and a sleep to hold stdin open, all of which returned the same nothing ^[3].

The other two iron rules in the writeup have the same shape. stdout is the protocol channel, so any non-JSON output pollutes the message stream and the client can parse no response at all ^[7]. That makes a stray debug print in code shared with the ordinary CLI harmless in one caller and fatal in the other, which is precisely the sort of asymmetry a unit test on a pure function cannot express. And `close` on stdin means the input stream ended, not that in-flight callbacks finished ^[8], so a handler can be correct in isolation and still have its last reply truncated in production.

The shipped fix is where the story gets honest. It guards the exit by comparing `process.argv[2]` against the strings `mcp-server` and `mcp` ^[9], while the article's own first rule says to extract a long-running abstraction such as `isLongRunning` rather than enumerate specific commands, and names `--watch` modes as long-running too ^[10]. The author flags that the guard's limitation surfaced the same day, under the heading Bug #1.5 ^[11]. A literal argv position check breaks the moment a global flag precedes the subcommand.

One more number. The piece asks how there could be a bug when 404 tests were green, having already reported 401 of 404 passing ^[1], which leaves three that were not ^[13]. The count quoted in the suite's defence is not the count the suite reported, and that gap is the same class of error as the bug: a property assumed at the boundary, never asserted there.