filesystem: tools/list succeeds without initialize handshake (MCP lifecycle bypass)

[pzr21]

Describe the bug
The @modelcontextprotocol/server-filesystem MCP server accepts and successfully handles tools/list before the client completes the required MCP lifecycle handshake (initialize → notifications/initialized). The server returns a normal JSON-RPC result instead of rejecting the request as out-of-order.

This breaks the expected MCP session state machine: compliant clients assume that only initialize is valid until the handshake completes. Allowing other methods early can mask misconfigured clients, weaken assumptions used by security tooling, and make session-scoped state (capabilities, auth context, subscriptions) harder to reason about.

Environment
OS: Linux (Proxmox VE host)
MCP server build: ships with current Cursor Desktop (Node-based, secure-filesystem-server v0.2.0, per server log line "serverInfo":{"name":"secure-filesystem-server","version":"0.2.0"})

To Reproduce
Start the filesystem MCP server with a valid allowed directory, e.g.:

npx -y @modelcontextprotocol/server-filesystem /tmp

Do not send initialize or notifications/initialized.

Send a JSON-RPC request for tools/list over stdio, e.g.:

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

Observe the response.

Expected behavior
Before the MCP handshake completes, the server should:

• Reject all methods except initialize (and any explicitly documented pre-init exceptions, if the spec allows them).
• Return a structured JSON-RPC error (e.g. invalid request / server not initialized), not a successful result.
• Optionally log a clear diagnostic on stderr indicating that the client violated lifecycle ordering.

After a valid initialize + notifications/initialized sequence, tools/list should succeed as usual.

Actual behaviour
Without any prior initialize call, tools/list is executed successfully and the server returns a JSON-RPC response containing result (tool enumeration), as if the session were already initialized.

[nakshatra-nahar]

Confirmed against current main (b1e1eb1). Built src/filesystem locally, piped a bare tools/list request into the stdio server with no initialize first, and got back a full successful result with all 14 tools — exactly as @pzr21 described.

I traced the dispatch path through @modelcontextprotocol/sdk (^1.29) and the SDK doesn't gate non-init requests at the protocol layer — Server only attaches oninitialized as a callback and stores _clientCapabilities on initialize, but every other request is dispatched immediately. So this isn't filesystem-specific; every reference server in the repo is affected. Fixing it properly is an SDK-level change in modelcontextprotocol/typescript-sdk, but a localized server-level fix is straightforward and avoids users waiting on an SDK release.

If maintainers are open to it, I'd like to send a PR scoped to filesystem only, with the following shape:

• Module-scoped handshakeComplete flag in src/filesystem/index.ts, set to true at the top of the existing server.server.oninitialized callback (line 731) — before the roots-fetch, so gating doesn't depend on roots discovery.
• A small withHandshakeGuard(handler) wrapper that throws new McpError(ErrorCode.InvalidRequest, "Request received before MCP initialization handshake completed") when the flag is false. The SDK converts the throw into a proper JSON-RPC error response.
• Apply the wrapper at the 14 server.registerTool(...) sites. Notifications (notifications/roots/list_changed) intentionally left ungated — JSON-RPC notifications have no response channel.

Tests would land alongside as a new src/filesystem/__tests__/handshake-gating.test.ts, using the same spawn-the-server-and-read-stdio pattern as startup-validation.test.ts. Two cases: (1) tools/list before initialize returns { error: { code: -32600, ... } }, (2) full initialize → notifications/initialized → tools/list succeeds.

A few decisions I'd like guidance on before sending the PR:

1. Scope: filesystem-only is the right scope for this PR, yes? Or would maintainers prefer I open a parallel issue at typescript-sdk and wait for an SDK-level fix?
2. Other servers in this repo (everything, fetch, git, memory, sequentialthinking, time) — should the same fix be applied as a follow-up PR per server, or only addressed once an SDK-level fix lands?
3. Error code — ErrorCode.InvalidRequest (-32600) seems right per JSON-RPC. The MCP spec doesn't define a more specific code for pre-handshake violations — would you want any specific wording in the message?

Happy to send the PR once you confirm the approach. Thanks!

CC: @olaservo