Problem
The Getting Started guide suggests running uvx --from memtomem memtomem-server as a diagnostic ("Verify: uvx --from memtomem memtomem-server should start without errors"), framed as a lightweight connectivity check for a first-time user.
Two issues with this guidance:
1. "Should start without errors" is misleading
When you run the MCP stdio server bare in a terminal, the TTY sends stray bytes (prompt noise, \n) to stdin, which the server parses as JSON-RPC and rejects. Real output a first-timer sees:
[04/22/26 23:20:49] ERROR Received exception from stream: 1
validation error for JSONRPCMessage
Invalid JSON: EOF while parsing a value
at line 2 column 0 [type=json_invalid,
input_value='\n', input_type=str]
The server is working correctly — it's just rejecting non-JSON input. But the user following the docs sees "ERROR" and reasonably concludes their install is broken.
2. The verify command has a hidden side effect
memtomem-server initializes ~/.memtomem/ on startup (creates memtomem.db + .server.pid) even if the user never ran mm init. Reproduction:
rm -rf ~/.memtomem/
uvx --from memtomem memtomem-server </dev/null # exits quickly on EOF
ls -la ~/.memtomem/
# -> memtomem.db (204KB), .server.pid
A first-time user who "just wants to verify the install works" ends up with a populated state dir and no way to know, because the docs present this as a read-only check.
Suggested direction
- Replace the verify command with something side-effect-free. Options:
uvx --from memtomem memtomem-server --version (if a version flag exists; if not, add one)
uvx --from memtomem mm --version
- A proper MCP
initialize handshake redirected from stdin — noisy to document, but at least truthful
- Separately: the
stdin_invalid_json error handler could downgrade TTY-origin garbage to DEBUG, so bare-tty launches at least don't paint the terminal with ERROR lines when no real client is attached.
- Document the state-dir creation behavior explicitly, or gate DB init behind an explicit
initialize RPC rather than on server startup.
Repro context
Fresh-install smoke test, 2026-04-22, macOS 25.4.0, uv 0.5.x, memtomem==0.1.23 pulled via uvx.
Problem
The Getting Started guide suggests running
uvx --from memtomem memtomem-serveras a diagnostic ("Verify:uvx --from memtomem memtomem-servershould start without errors"), framed as a lightweight connectivity check for a first-time user.Two issues with this guidance:
1. "Should start without errors" is misleading
When you run the MCP stdio server bare in a terminal, the TTY sends stray bytes (prompt noise,
\n) to stdin, which the server parses as JSON-RPC and rejects. Real output a first-timer sees:The server is working correctly — it's just rejecting non-JSON input. But the user following the docs sees "ERROR" and reasonably concludes their install is broken.
2. The verify command has a hidden side effect
memtomem-serverinitializes~/.memtomem/on startup (createsmemtomem.db+.server.pid) even if the user never ranmm init. Reproduction:A first-time user who "just wants to verify the install works" ends up with a populated state dir and no way to know, because the docs present this as a read-only check.
Suggested direction
uvx --from memtomem memtomem-server --version(if a version flag exists; if not, add one)uvx --from memtomem mm --versioninitializehandshake redirected from stdin — noisy to document, but at least truthfulstdin_invalid_jsonerror handler could downgrade TTY-origin garbage toDEBUG, so bare-tty launches at least don't paint the terminal withERRORlines when no real client is attached.initializeRPC rather than on server startup.Repro context
Fresh-install smoke test, 2026-04-22, macOS 25.4.0,
uv 0.5.x,memtomem==0.1.23pulled viauvx.