SSEClientTransport drops path prefix when endpoint URL is not on the HTTP root (similar to python-sdk#563)

Bắt đầu tại SSEClientTransport.Connect, nơi sự kiện Endpoint đầu tiên được phân giải từ Endpoint đã cấu hình, và so sánh các URL tái hiện được ghi trong tài liệu với URL message thu được. Bổ sung coverage cho một tiền tố đường dẫn không phải root và cho một sự kiện Endpoint bắt đầu bằng /; hoàn tất khi các POST tiếp theo vẫn giữ tiền tố định tuyến mà không làm hỏng việc phân giải Endpoint thông thường.

Describe the bug
SSEClientTransport drops the path prefix of the configured Endpoint when resolving the message endpoint from the first endpoint SSE event.

In Connect, the message endpoint is derived like this:

// Connect connects through the client endpoint.
func (c *SSEClientTransport) Connect(ctx context.Context) (Connection, error) {
    parsedURL, err := url.Parse(c.Endpoint)
    if err != nil {
        return nil, fmt.Errorf("invalid endpoint: %v", err)
    }
    req, err := http.NewRequestWithContext(ctx, "GET", c.Endpoint, nil)
    if err != nil {
        return nil, err
    }
    httpClient := c.HTTPClient
    if httpClient == nil {
        httpClient = http.DefaultClient
    }
    req.Header.Set("Accept", "text/event-stream")
    resp, err := httpClient.Do(req)
    if err != nil {
        return nil, err
    }

    msgEndpoint, err := func() (*url.URL, error) {
        var evt Event
        for evt, err = range scanEvents(resp.Body) {
            break
        }
        if err != nil {
            return nil, err
        }
        if evt.Name != "endpoint" {
            return nil, fmt.Errorf("first event is %q, want %q", evt.Name, "endpoint")
        }
        raw := string(evt.Data)
        return parsedURL.Parse(raw)
    }()
    if err != nil {
        resp.Body.Close()
        return nil, fmt.Errorf("missing endpoint: %v", err)
    }

    // From here on, the stream takes ownership of resp.Body.
    s := &sseClientConn{
        client:      httpClient,
        msgEndpoint: msgEndpoint,
        incoming:    make(chan []byte, 100),
        body:        resp.Body,
        done:        make(chan struct{}),
    }

    go func() {
        defer s.Close() // close the transport when the GET exits

        for evt, err := range scanEvents(resp.Body) {
            if err != nil {
                return
            }
            select {
            case s.incoming <- evt.Data:
            case <-s.done:
                return
            }
        }
    }()

    return s, nil
}

When the server sends an endpoint event whose data starts with / (for example /messages?sessionId=123), parsedURL.Parse(raw) replaces the entire path of c.Endpoint instead of preserving the prefix.

So if c.Endpoint is:

http://192.168.1.57:8000/mcp/http://192.168.1.30:8088/sse

and the server sends:

event: endpoint
data: /messages?sessionId=123

then msgEndpoint becomes:

http://192.168.1.57:8000/messages?sessionId=123

instead of:

http://192.168.1.57:8000/mcp/http://192.168.1.30:8088/messages?sessionId=123

This makes it impossible to use SSEClientTransport with an MCP server that is mounted behind a path prefix or with a reverse proxy that encodes routing information in the path.

This is very similar to the issue reported in the Python SDK in modelcontextprotocol/python-sdk#563.

---

To Reproduce
Steps to reproduce the behavior:

1. Put an MCP SSE server behind a reverse proxy that exposes it at a non-root path, for example:

   http://192.168.1.57:8000/mcp/http://192.168.1.30:8088/sse
   

2. Have the backend server send an endpoint event like:

   event: endpoint
   data: /messages?sessionId=123
   

3. In a Go client, connect using SSEClientTransport:

   transport := &mcp.SSEClientTransport{
       Endpoint: "http://192.168.1.57:8000/mcp/http://192.168.1.30:8088/sse",
   }
   
   client := mcp.NewClient(&mcp.Implementation{
       Name:    "mcp-client",
       Version: "dev",
   }, nil)
   
   ctx := context.Background()
   session, err := client.Connect(ctx, transport, nil)
   if err != nil {
       log.Fatalf("Connect failed: %v", err)
   }
   defer session.Close()
   

4. Check the HTTP traffic on 192.168.1.57:8000 (e.g. reverse proxy logs). You’ll see:

   • The initial GET goes to /mcp/http://192.168.1.30:8088/sse (correct).
   • Subsequent POSTs go to /messages?sessionId=123 (missing the /mcp/http://192.168.1.30:8088 prefix), which breaks any path-based routing.

---

Expected behavior
The message endpoint resolution should not silently drop the original path prefix of c.Endpoint when the server sends the endpoint event.

For example, for:

• Endpoint = "http://192.168.1.57:8000/mcp/http://192.168.1.30:8088/sse"
• endpoint event data /messages?sessionId=123

I would expect msgEndpoint to still include the prefix (or at least have a way to preserve it), so that path-based reverse proxies remain usable.

---

Logs
Example reverse-proxy logs (simplified):

# Initial SSE connection
192.168.1.100 - - "GET /mcp/http://192.168.1.30:8088/sse HTTP/1.1" 200 -

# Subsequent POST from go-sdk SSE client (missing prefix)
192.168.1.100 - - "POST /messages?sessionId=123 HTTP/1.1" 404 -

The proxy only routes /mcp/http://192.168.1.30:8088/..., so the POST to /messages fails.

---

Additional context
Two questions / possible directions where I’d really appreciate guidance from the maintainers:

1. Can / should servers return a “relative” path in the endpoint event?
   Right now many examples use a leading slash, e.g. data: /messages?sessionId=123.
   If instead the server returned something like data: messages?sessionId=123 (no leading /), then parsedURL.Parse(raw) would treat it as relative to the original endpoint path and the prefix would be preserved.

   • Is such a relative URI considered valid according to the MCP spec for endpoint events?
   • If yes, should server implementations be encouraged to do this when they expect to live behind path prefixes?

2. Would it make sense for the Go client to support configuring two paths / URLs?
   For example:

   • One URL for the initial SSE GET (Endpoint), and
   • Another explicit URL / base URL for the message POST endpoint (e.g. MessageEndpoint or similar), instead of always deriving it from Endpoint + evt.Data.
     This would make it much easier to support path-based reverse proxies (and setups where routing information is encoded in the path) without having to modify the MCP server itself.

---

Current workaround

As a temporary workaround, I’m using a rather ugly “double-prefixed” endpoint and a very permissive server handler:

• Client-side Endpoint configured in SSEClientTransport:

  http://192.168.1.57:8000/mcp/http://192.168.1.30:8088/mcp/http://192.168.1.30:8088/
  

• After the reverse proxy on 192.168.1.57:8000, this is forwarded to the backend as:

  http://192.168.1.30:8088/mcp/http://192.168.1.30:8088/
  

• The MCP server (which also uses go-sdk) sends an endpoint event like:

  event: endpoint
  data: /mcp/http://192.168.1.30:8088/?sessionid=xxx
  

• After the same proxy logic, the final POSTs end up at:

  http://192.168.1.30:8088/?sessionid=xxx
  

On the server side I’m using the go-sdk SSE handler mounted at the root, without any path restrictions:

sseHandler := mcp.NewSSEHandler(s, nil)
err := http.ListenAndServe(address, sseHandler)
if !errors.Is(err, http.ErrServerClosed) {
    slog.Error("failed to listen and serve", "error", err)
    os.Exit(1)
}

Because NewSSEHandler is handling all incoming paths and only cares about the query parameter sessionid, this setup happens to work and the session ID is parsed correctly. However, it’s clearly a hacky workaround and illustrates how difficult it is to use SSEClientTransport cleanly when the server is behind a path-based reverse proxy.

• go-sdk version: v1.1.0
• Go version: 1.25.4
• OS: macOS