implements the notifications/initialized method #84
Conversation
- According to https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle, "After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations". - This implementation just replies with an empty response (same as ping).
There was a problem hiding this comment.
Yeah, the current behavior that results in the following error is problematic.
{jsonrpc: "2.0", id: "123", error: {code: -32601, message: "Method not found", data: "notifications/initialized"}}
It must be able to respond to notifications/initialized in accordance with the specification.
There was a problem hiding this comment.
This should be implemented as an actual notification, not a method. See https://www.jsonrpc.org/specification#notification
|
I have changed it to return nil and fixed the test case to not send an |
|
@jkraemer A single handler suffices because we delegate response handling to the underlying json_rpc_handler gem and it's responsible for handling nil results. |
|
Also notice that the response code for this request should be 202 (:accepted). In order to have this working with claude.ai I had to implement the following unglines: status, headers, body = @transport.handle_request(rack_request)
if params[:method] == "notifications/initialized"
status = 202
end |
|
It seems like Claude.ai is wrong here. Both rpc and MCP specs state that notification does not require a response. |
I agree, but I am not sure how we can raise this with them. |
|
There is a "give feedback" button in Claude Desktop settings; it opens a Google Form. |
I think we need to differentiate between JSON-RPC and HTTP here - even a 'no response' in JSON-RPC land requires some HTTP status code on the response if HTTP is the underlying protocol over which JSON-RPC messages are transported. I think a 202 with an empty body is entirely appropriate in this case. |
It probably should accept any "successful" HTTP status code, given that
PS. Sorry for the offtopic. |
|
I couldn't glean from claude.ai's HTML what framework it's built with (and didn't spend too much time with it), but both Claude Desktop and the Inspector are likely using the official TS SDK. We can check what the TS SDK client is doing. I can also ask the steering committee what SDK claude.ai is using and why they chose to be strict about 202. I agree that clients should just be happy about 20x.. And the Ruby SDK can return a 202 for all notifications, not just this one. |
According to https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle, "After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations".
This implementation just replies with an empty response (same as ping).
Motivation and Context
Claude Code assumed the MCP server wasn't working when this method was not handled gracefully.
How Has This Been Tested?
test case added, works in my app.
Types of changes