`failed to reconnect: Not Found` after initalize in stateless HTTP `POST` server

[jpmcb]

I have an MCP server that only servers JSON over HTTP POST in a stateless fashion. It works like so:

❯ curl http://localhost:3000/mcp \
      -X POST \
      -H 'accept: application/json, text/event-stream' \
      -H 'content-type: application/json' \
       -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "ping"
  }' -vvv
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:3000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:3000...
* Connected to localhost (::1) port 3000
> POST /mcp HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/8.7.1
> accept: application/json, text/event-stream
> content-type: application/json
> Content-Length: 55
>
* upload completely sent off: 55 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 38
< Date: Tue, 02 Sep 2025 19:49:45 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
* Connection #0 to host localhost left intact
{"jsonrpc":"2.0","id":"1","result":{}}

But when attempting to us a very simple go-sdk with this like so:

package main

import (
	"context"
	"log"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

func main() {
	ctx := context.Background()

	// Create a new client, with no features.
	client := mcp.NewClient(&mcp.Implementation{Name: "mcp-client", Version: "v1.0.0"}, nil)

	// Connect to a server over stdin/stdout
	transport := &mcp.StreamableClientTransport{Endpoint: "http://localhost:3000/mcp"}
	session, err := client.Connect(ctx, transport, nil)
	if err != nil {
		log.Fatal(err)
	}
	defer session.Close()

	err = session.Ping(ctx, nil)
	if err != nil {
		log.Fatalf("could not ping: %v", err)
	}
}

I get this error:

❯ go run main.go
2025/09/02 15:54:35 could not ping: calling "ping": failed to reconnect: Not Found
exit status 1

It seems that this client successfully connects and initializes (as I see a log in my server that Received notification: notifications/initialized) but does not reuse the connection:

go-sdk/mcp/streamable.go

Lines 1309 to 1313 in 07b65d7

	if resp.StatusCode < 200 || resp.StatusCode >= 300 {
	resp.Body.Close()
	c.fail(fmt.Errorf("failed to reconnect: %v", http.StatusText(resp.StatusCode)))
	return
	}

Since the error message is Not found, I'm wondering if my server is returning a 404 for some reason.

But, a very similar program works fine with mark3labs/mcp-go:

package main

import (
	"context"
	"fmt"
	"log"

	"github.com/mark3labs/mcp-go/client"
	"github.com/mark3labs/mcp-go/client/transport"
	"github.com/mark3labs/mcp-go/mcp"
)

func main() {
	ctx := context.Background()

	// Create HTTP transport directly
	httpTransport, err := transport.NewStreamableHTTP(
		"http://localhost:3000/mcp",
	)
	if err != nil {
		log.Fatalf("Failed to create HTTP transport: %v", err)
	}
	defer httpTransport.Close()

	// Create client with sampling support
	mcpClient := client.NewClient(
		httpTransport,
	)

	err = mcpClient.Start(ctx)
	if err != nil {
		log.Fatalf("Failed to start client: %v", err)
	}

	// Initialize the MCP session
	initRequest := mcp.InitializeRequest{
		Params: mcp.InitializeParams{
			ProtocolVersion: mcp.LATEST_PROTOCOL_VERSION,
			Capabilities:    mcp.ClientCapabilities{},
			ClientInfo: mcp.Implementation{
				Name:    "http-client",
				Version: "0.0.1",
			},
		},
	}

	_, err = mcpClient.Initialize(ctx, initRequest)
	if err != nil {
		log.Fatalf("Failed to initialize MCP session: %v", err)
	}

	toolsResult, err := mcpClient.ListTools(ctx, mcp.ListToolsRequest{})
	if err != nil {
		log.Fatalf("Failed to list tools: %v", err)
	}

	for i, tool := range toolsResult.Tools {
		fmt.Printf("  %d. %s - %s\n", i+1, tool.Name, tool.Description)
	}
}

❯ go run main.go
  1. add - Adds two numbers together and returns the result.
  2. subtract - Subtracts the second number from the first and returns the result.
  3. multiply - Multiplies two numbers together and returns the result.
  4. divide - Divides the first number by the second and returns the result.
  5. power - Raises the first number to the power of the second number.
  6. sqrt - Calculates the square root of the given number.
  7. modulo - Returns the remainder of dividing the first number by the second.
  8. factorial - Calculates the factorial of the given integer.

This also works fine with inspector:

I'm at abit of a loss as to what is going on here. My main questions are:

1. Does go-sdk support new HTTP connections when the server closes the connection? I.e., can it churn the connection to do a new method after initialization?
2. What steps can I take to debug this further? For the curious, this is the server I'm using: https://github.com/zuplo/mcp/tree/main/examples/calculator
3. What is the code path that a "Not found" would be surfaced here? Very curious!

[jpmcb]

Ahhh, I think I see what's happening:

go-sdk/mcp/streamable.go

Line 1416 in 07b65d7

req, err := http.NewRequestWithContext(c.ctx, http.MethodGet, c.url, nil)

In the re-connect path, there's a GET to the endpoint: this always will fail for me since my server only works over POST. Seems this may actually be a problem with my server implementation since it also seems the stateless implementation for the typescript SDK has a POST for handling most messages but a shadow GET and DELETE for non-existent session management: https://github.com/modelcontextprotocol/typescript-sdk?tab=readme-ov-file#without-session-management-stateless

So, now, my question is: have I missed something in the spec that defines how stateless HTTP streamable should work? I know it's not very well defined but I swear (at one point or another) HTTP streamable in the ^ typescript-sdk only had a POST route.

I also wonder if go-sdk needs to loosen its implementation abit? It's curious that mark3labs/mcp-go and the Inspector "Just work ™️" but, again, I guess there isn't really a well defined standard for how stateless HTTP streamable should work out in the wild.

[findleyr]

@jpmcb there's nothing in the spec that describes how stateless HTTP streamable transport should work, though there's been discussion about codifying how it works in practice.

It definitely sounds like the go-sdk is being too strict. Does the typescript server return 405 for GET? If so, then the client should just ignore the hanging GET and not fail the connection.

Additionally, we should verify that in stateless mode the server sends 405 for the GET (I'll look at the code when back at a computer).

Thanks for the report. We'll fix this ASAP, unless you want to take a stab at it.

[jpmcb]

Does the typescript server return 405 for GET?

Unfortunately, no, in my implementation, it returns a hard 404.

Sure thing - since I'm knee deep, I can take a quick look at it!

[findleyr]

Ok, I just took a brief look at the code. A couple notes:

• Server-side, I think there is a bug (a recent regression): we do check for 'sessionless' mode here:
  

  go-sdk/mcp/streamable.go

  Line 174 in 07b65d7

  if req.Method == http.MethodGet && sessionID == "" {

  
  The condition should not be sessionID == "", it should be h.opts.Stateless. (subsequent to that logic being added, we differentiated 'stateless' mode from 'sessionless' mode -- see below).
• Client-side, I think we do the right thing, according to a strict reading of the spec:

  go-sdk/mcp/streamable.go

  Line 1304 in 07b65d7

  if resp.StatusCode == http.StatusMethodNotAllowed && persistent {

  
  You can see that if the server returns MethodNotAllowed, we don't fail the connection. Otherwise, something is wrong, and we fail the connection.

So I think we're correct, and it is wrong that the typescript SDK returns 404 rather than 405. I'm not sure what to do here: of course we want to make it Just Work, but if the hanging GET is broken, and the client is naive (and most clients are naive), then the client session is arguably corrupted.

The client shouldn't need to know if the server is stateless: that's an artifact of the server implementation. So, it's perfectly reasonable for the client to send GET, and the spec is pretty clear (https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#listening-for-messages-from-the-server):

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.

Aside: "Stateless" vs. "Sessionless":

Stateless mode is where there's no MCP state: the initialization lifecycle is not checked, and sessionID headers are ignored. Things like server->client RPCs and state-affecting client RPCs (log levels, resource subscriptions) can't work. This allows the server to be distributed.

Sessionless mode is where there's no session ID. This is actually different from stateless mode, because the 6-18 version of the spec requires the client to forward on the session ID header on subsequent requests. This means that even for stateless servers, the session ID can be used as a key for application-level state (even though the MCP session is stateless).

Some SDKs (like typescript) don't differentiate these two modes, but others, including the Go SDK, do differentiate them. It's useful to be able to have a distributed server that uses session ID as a key for application level state stored in a database.

[findleyr]

BTW, regardless of what we decide here, a concrete action item is to improve the error message from the go-sdk.

[findleyr]

@jpmcb please let me know how you'd like to proceed. From the investigation above, it sounds like we should at least:

1. Fix the server-side condition that returns 405 for GET (with a test).
2. Improve the client-side error message when the stream fails because the GET is broken.

[jpmcb]

Great info - yes, I believe you're correctly: my server implementation is wrong since it 404s on GET and DELETE (since I don't even have those in my router).

So, yes, a fix for the server-side condition and adding a test. And improve the client side error since that essentially is an invalid session/request as you noted.

---

I'll have time to get to this over the weekend: otherwise, if you're already in those bits, feel free to cut it in!

[findleyr]

@jpmcb thanks for confirming.

Since I'm thinking about this, I'll make these improvements now (we're in crunch time with the RC scheduled for next week, and so I'd like to incorporate your feedback ASAP).