implements the notifications/initialized method

[jkraemer]

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

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

[koic]

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.

[atesgoral]

This should be implemented as an actual notification, not a method. See https://www.jsonrpc.org/specification#notification

[jkraemer]

I have changed it to return nil and fixed the test case to not send an id. I did not find any code dedicated to handling incoming notifications outside the regular method call handling - do we leave it at that for now or would it make sense to have a separate handler for anything notifications/*?

[atesgoral]

@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.

[alexandru-calinoiu]

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)ifparams[:method] == "notifications/initialized"status=202end

[K4sku]

It seems like Claude.ai is wrong here.

Both rpc and MCP specs state that notification does not require a response.
However, python SDK does return 202

[alexandru-calinoiu]

It seems like Claude.ai is wrong here.

Both rpc and MCP specs state that notification does not require a response. However, python SDK does return 202

I agree, but I am not sure how we can raise this with them.

[K4sku]

There is a "give feedback" button in Claude Desktop settings; it opens a Google Form.
I just submitted a bug there. I have passed a link to this PR.

[jkraemer]

It seems like Claude.ai is wrong here.

Both rpc and MCP specs state that notification does not require a response. However, python SDK does return 202

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.

[K4sku]

It seems like Claude.ai is wrong here.
Both rpc and MCP specs state that notification does not require a response. However, python SDK does return 202

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

1. It's not documented anywhere.
2. Claude Code and MCP Inspector are fine with 200.

PS. Sorry for the offtopic.

[atesgoral]

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.

[koic]

As for the response status, it is handled separately in #84 and #114, so I think this PR can be merged independently of them.

@jkraemer Can you squash your commits into one?

[jkraemer]

@jkraemer Can you squash your commits into one?

Done!

[koic]

Thanks!