Failed to Initialize MCP server connection

[Mason Gao]

Hi
Im trying to build a custom Rovo Mcp client using it's API endpoint, this is the request I send to initialize the MCP session
URI: https://mcp.atlassian.com/v1/mcp
Headers:
Accept: application/json, text/event-stream

Cache-Control: no-cache

Content-type: application/json

MCP-Protocol-Version: 2025-06-18

Authorization: Bearer <My Oauth token>

Body:

{
"jsonrpc" : "2.0",
"method" : "initialize",
"id" : "<my ID>",
"params" : {
"protocolVersion" : "2025-06-18",
"capabilities" : { },
"clientInfo" : {
"name" : "agentscope-java",
"title" : "AgentScope Java Framework",
"version" : "1.0.9"
}
}
}

The response shows it is not a valid initialize request 
Status Code:
400
Body:
{"jsonrpc":"2.0","error":{"code":-32600,"message":"Request must be an initialize request if no session ID is provided."}}

The request I sent to mcp server is constructed by agentScope framework, which utilize following maven package to encapsulate the request 

<dependency>
  <groupId>io.modelcontextprotocol.sdk</groupId>
  <artifactId>mcp</artifactId>
  <version>0.17.0</version>
  <scope>compile</scope>
</dependency>

Is there anything missing for my initialize request? Much appreciate for your suggestions. 

[Mason Gao]

Update, it seems working if I dont specify content type in the header, however, server will send a request back with status code 202, and content-type "text/plain". 
The MCP package for java cannot process request with content type other than application/json and text/event-stream(and header send by server does not specify content length so it wont be treated as empty content), so it would throw a exception for it. Are there any methods to make server return only application/json or text/event-stream? or any methods to send request so it can force server to send content length back

  Groupid: io.modelcontextprotocol.sdk
  Artifact id： mcp
  Version: 0.17.0

[Dilip Venkatesh]

Below are the steps on how you would do it

Step 1: Initialize 

Creates a new MCP session on mcp.atlassian.com.

curl -i -sS -X POST \
-H "Authorization: Basic or bearer" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
"https://mcp.atlassian.com/v1/mcp" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {},
"clientInfo": {
"name": "curl-test",
"version": "1.0.0"
}
}
}'

Expected response: 200 OK, content-type: text/event-stream

Important: Grab Mcp-Session-Id from the response headers.

Sample body will look like:

 event: message
data: {"result":{"protocolVersion":"2024-11-05","capabilities":{"logging":{},"tools":{"listChanged":true},"resources":{}},"serverInfo":{"name":"atlassian-mcp-server","version":"1.0.0"}},"jsonrpc":"2.0","id":1}

Step 2: Send notifications/initialized

Send the initialized notification using the session id from Step 1.

 curl -i -sS -X POST \
-H "Authorization: Basic or bearer" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Mcp-Session-Id: <session-id-from-step-1>" \
"https://mcp.atlassian.com/v1/mcp" \
-d '{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}'

Expected response: 202 Accepted

Note: This is a notification (no id).

Step 3: List Available Tools

curl -sS -X POST \
-H "Authorization: Basic or bearer" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Mcp-Session-Id: <session-id>" \
"https://mcp.atlassian.com/v1/mcp" \
-d '{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/list",
"params": {}
}'Expected response: SSE event: message with the tool list in data: ....

Step 4: Call a Tool

Example: atlassianUserInfo on prod.

 curl -sS -X POST \
-H "Authorization: Basic or bearer" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Mcp-Session-Id: <session-id>" \
"https://mcp.atlassian.com/v1/mcp" \
-d '{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "atlassianUserInfo",
"arguments": {}
}
}'

 

Recommended headers (every request):

• Accept: application/json, text/event-stream
• Content-Type: application/json
• plus Authorization: Basic or bearer and
• (after initialize) Mcp-Session-Id: <session-id>

Note on notifications/initialized: it typically returns 202 Accepted and may come back with content-type: text/plain and/or an empty body. Some responses may omit Content-Length, so clients should treat 202 as “no body expected” and tolerate empty/plain responses (don’t require SSE/JSON on that call).

[Mason Gao]

Hi Dilip
Thank you so much for your answer, what happened in this case is the dependency used to handle streamable http response is io.modelcontextprotocol.client.transport (it is used indirectly by one of my dependencies so I have no control over it), and it process response like below

IF response code >200 and <300
          IF "content length" = 0 OR "content type" is null

                Process the response as empty response

          ELSE IF "content type" = "application/json"
                Process the response as Json response

          ELSE IF "content type" = “text/event-stream”

                Process the response as event stream response
          ELSE

                Throw exception showing unsupported content type

As you can see the it is not capable of processing responses that omits content-length and have a content type of text/plain. Is there any method to send request so the response include content-length or have a valid content type? Or any suggestion that can address this situation?

[Dilip Venkatesh]

Hi Mason,

I see that you are using an old version of the mcp client sdk (0.17.0)

The issue you are talking about is already reported and closed by the MCP java sdk.

Github issue - https://github.com/modelcontextprotocol/java-sdk/issues/748

Release 0.17.2 there is a mention of 202 handling for notifications.

https://github.com/modelcontextprotocol/java-sdk/releases/tag/v0.17.2

v0.17.2

This release:

• Addresses mostly the testing infrastructure issues.
• Fixes a client-side issue with servers that process client-initiated notifications with a 202 Accepted HTTP Header.