Fix MCP handshake failure with hosts that probe via server/discover - #31
Merged
Merged
Conversation
The GitHub Copilot CLI (and similar hosts) send an optimistic `server/discover` request before the standard `initialize`. rmcp's handshake treats the first non-ping request as the initialize request; when it isn't, serve() returns an error and the process exits, closing stdin before the host's fallback `initialize` arrives (broken pipe), so the server never starts. Wrap the stdio transport in a DiscoveryGuard that replies to any pre-initialize request with JSON-RPC -32601 (Method not found) and keeps waiting, letting the host's fallback initialize succeed. This mirrors how spec-compliant servers (e.g. mind-map) already behave. Add end-to-end tests that replay the probe-then-initialize sequence over an in-memory transport and confirm a normal handshake is unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Installing the latest release and enabling it in the GitHub Copilot CLI fails at startup:
Root cause
The Copilot CLI (and similar hosts) send an optimistic
server/discoverrequest before the standardinitialize. A spec-compliant server is expected to reply to the unknown method with-32601 Method not foundand stay alive, after which the host falls back to the normalinitializehandshake. The runtime logs confirm this:rmcp's
serve_serverhandshake instead treats the first non-pingrequest as theinitializerequest. When it isn't,serve()returns an error,mainexits (code 1), and stdin closes before the host's fallbackinitializearrives — the client then hits a broken pipe and the server never starts. (mind-map, which uses the Go SDK, tolerates this and works, which is why other servers were fine.)Fix
Wrap the stdio transport in a small
DiscoveryGuard(crates/devcontainer-mcp/src/discovery_guard.rs) that, before initialization, answers any request that isn'tinitialize/pingwith JSON-RPC-32601 Method not foundand keeps waiting.pingandinitializepass through untouched, and once initialized the guard is fully transparent. This lets the host's fallbackinitializesucceed, matching spec-compliant server behavior.No dependency changes.
Tests
Adds two end-to-end tests that run the real
DevContainerMcpserver behindDiscoveryGuardover an in-memory transport (mirroring the reference server's test style):survives_pre_initialize_discover_probe— replaysserver/discover→initialize→initialized→tools/list, asserting the probe gets-32601, the server stays alive, and tools list successfully.normal_handshake_still_works— a plain handshake is unaffected by the wrapper.Verification
Built and tested inside the devcontainer:
cargo test -p devcontainer-mcp→ both tests passcargo clippy -p devcontainer-mcp-core -p devcontainer-mcp -- -D warnings→ cleanserver/discoverreturns-32601, theninitialize+tools/listreturn 46 tools, exit 0, empty stderr.