Repository navigation
Can't invoke Streamable HTTP MCP server implemented with Micronaut MCP #582
Description
I implemented a Streamable HTTP MCP server with the Micronaut MCP module:
https://github.com/glaforge/mn-mcp-server
It exposes a couple methods:
current-moon-phase(): to get the current phase of the moonmoon-phase-at-date("2025-09-28"): to get the phase at a certain date
You can call that server here with the MCP Inspector for testing:
https://mn-mcp-server-1029513523185.europe-west1.run.app/mcp/
The MCP inspector is totally fine with it, no error, I can list all the tools, call all the methods, etc.
I tried with the LangChain4j MCP module as well (which is a reimplementation of the protocol), with the following code:
https://gist.github.com/glaforge/809ccbad223886b0db03e679adcb7e85
And it also works totally fine with my server.
However, when I can from the Agent Development Kit for Java (ADK), it fails.
As ADK is using the official MCP SDK, I tried to reproduce the problem with the SDK directly, to remove ADK from the equation, and it fails in the same way.
I reproduced the problem with the following code:
https://gist.github.com/glaforge/741edcad883b27268ab10249400ce6d6
I'm seeing this stacktrace (same as within ADK for Java):
https://gist.github.com/glaforge/afd1194ece6bc909b091a946c030dc27
i.e.
io.modelcontextprotocol.spec.McpTransportException: Invalid SSE response. Status code: 405 Line: {"message":"Method Not Allowed","_links":{"self":{"href":"/mcp","templated":false}},"_embedded":{"errors":[{"message":"Method [GET] not allowed for URI [/mcp]. Allowed methods: [POST]"}]}}
at io.modelcontextprotocol.client.transport.ResponseSubscribers$SseLineSubscriber.hookOnNext(ResponseSubscribers.java:185)
at io.modelcontextprotocol.client.transport.ResponseSubscribers$SseLineSubscriber.hookOnNext(ResponseSubscribers.java:72)
...
21:04:44.389 [HttpClient-1-Worker-0] WARN io.modelcontextprotocol.client.transport.HttpClientStreamableHttpTransport -- Unknown media type text/html returned for POST in session [missing_session_id]
21:04:44.389 [HttpClient-1-Worker-0] WARN io.modelcontextprotocol.client.LifecycleInitializer -- Handling exception
java.lang.RuntimeException: Unknown media type returned: text/html
at io.modelcontextprotocol.client.transport.HttpClientStreamableHttpTransport.lambda$sendMessage$27(HttpClientStreamableHttpTransport.java:522)
...
Caused by: java.lang.RuntimeException: Unknown media type returned: text/html
at io.modelcontextprotocol.client.transport.HttpClientStreamableHttpTransport.lambda$sendMessage$27(HttpClientStreamableHttpTransport.java:522)
So I'm not sure if it's a problem on Micronaut's side or on the MCP SDK's side.
Maybe one is too strict with the spec, or not tolerant enough, I don't know.
But when I read the spec:
The server MUST provide a single HTTP endpoint path (hereafter referred to as the MCP endpoint)
that supports both POST and GET methods. For example, this could be a URL like
https://example.com/mcp.
The client MAY issue an HTTP GET to the MCP endpoint. This can be used to open an SSE stream,
allowing the server to communicate to the client, without the client first sending data via HTTP POST.
The server MUST either return Content-Type: text/event-stream in response to this HTTP GET,
or else return HTTP 405 Method Not Allowed, indicating that the server does not offer an SSE
stream at this endpoint.
It seems that Micronaut does the right thing: if a client tries to do a GET to do an SSE connection,
it gets a 405, which is the error Micronaut is returning.
Any idea what could be going wrong here @tzolov ?
Activity
Kehrlann commentedon Sep 30, 2025
@glaforge
The
McpSyncClient+HttpClientStreamableHttpTransportworks against our "stateless server implementation".When trying against your server, I'm seeing a 404 when the client sends
notifications/initialized(see MCP Initialization phase), but we expect a successful HTTP 2xx (we send 202).Since the language says the client MUST send this notification, I assume it's implied the server MUST accept it.
Now the spec seems to indicate that 202 is the "correct" response, see
#4in the streamable HTTP transport spec, unless the server cannot accept. What would "cannot accept" mean in this context, I am unsure.Using the following script to test:
Kehrlann commentedon Sep 30, 2025
And just now I see @sdelamo has fixed it 🤦 Could you please try again with the latest micronaut build @glaforge ?
glaforge commentedon Oct 1, 2025
Hi @Kehrlann ! Good to see you here 😄
I've just redeployed my Micronaut MCP server (still at the same address) with the new 0.0.8 version from @sdelamo from yesterday.
However, I'm still seeing the same errors right now.
glaforge commentedon Oct 1, 2025
And what's interesting is that other clients like LangChain4j's MCP support, Gemini CLI's MCP support, are all happy with the Micronaut server I deployed. The MCP SDK is quite strict compared to other clients.
Kehrlann commentedon Oct 1, 2025
Ah, I see.
So now the response is fixed, it'd not 404 anymore. However, we get:
So we have a
content-type: text/htmlwith no body. I think this is valid. The SDK gets tripped bycontent-typenot being eithertext/event-streamorapplication/json; because even the spec mandates those return types for JSONRPC-requests (see transports).We could look at the content-length and avoid being tripped up.
In the meantime, you can update either Micronaut or your frontend to strip that header.
Client: handle server responses with Content-Length: 0
glaforge commentedon Oct 1, 2025
@Kehrlann any change that you're going to make a release before Devoxx with the change in c4bf139 ? 😄
glaforge commentedon Oct 1, 2025
On the ADK integration of the MCP SDK, I noticed we use an outdated version of the SDK:
0.11.3instead of0.13.1.I'll try to get that version upgraded rapidly as well.
tzolov commentedon Oct 1, 2025
Hi @glaforge , we plan to have 0.14.0 release today or tomorrow. Will make sure that #588 is in
Client: handle server responses with Content-Length: 0
glaforge commentedon Oct 1, 2025
Awesome! Thank you both!
Client: handle server responses with Content-Length: 0
link #115926 Upgrade MCP SDK fork to upstream v0.18.2 for streamable …