go-sdk

Is your feature request related to a problem? Please describe I'm using the to implement an MCP server. Just as the underlying , my server is stateful, and I need to clean up resources when a session ends (e.g., deleting entries from a map). I am currently performing this cleanup by wrapping the in my own HTTP handler implementation, which allows me to directly handle requests from the client. While this works fine, I'm still not able to clean up sessions when the connection breaks due to timeouts or other network errors. Describe the solution you'd like Browsing around the SDK internals, I found there is already such a cleanup, but it's not yet exported: . I experimented with this locally to see if it fits my use case and was able to make it work. However, I found out that this cleanup isn't actually called yet when the client closes the session with a call explicitly. Ideally, I would like to replace my current HTTP handler for DELETE requests with a single cleanup function, so it would be beneficial if the would actually close the transport connection and session when handling the DELETE call. I've attached a full working diff in the details below: Describe alternatives you've considered Cleaning up resources just with a DELETE handler, but this alternative doesn't allow cleanup in error cases, which means my server will leak memory over time. Additional context _none_

This fixes a panic in the server-side per-request protocol metadata path when an inbound message has and new-protocol . The request decodes as notification-shaped, so returns new-protocol metadata without initialize params. Guard the protocol-version check before reading initialize params, allowing the existing request validation path to reject the malformed call instead of dereferencing nil. Tests: Fixes #1043

Describe the bug When the Go SDK server handles requests declaring the 2026-07-28 protocol version, only three tested result types (, , and ) include the field in their JSON responses. Other tested result types — including , , , , , and — omit entirely. The 2026-07-28 draft schema defines as a required field on the base type: The same constraint appears on the result schemas I checked in the generated , including , , , , , , , , , , , , , and . This appears to be a 2026-07-28 schema-compliance issue. The field appears to be set only for the multi-round-trip (MRTR) result path, while the schema requires it on result objects generally. Environment tested: snapshot from 2026-06-28: Server used: Transports: stdio and Streamable HTTP (stateless) To Reproduce Steps to reproduce the behavior: 1. Start the Go SDK server with 2026-07-28 support enabled. 2. Send a request with . 3. Observe that the response does not contain . 4. Repeat with , , , . 5. Observe that none of these responses contain . 6. Send a request for a known tool. 7. Observe that this response does contain . Example request: Expected behavior All result objects in 2026-07-28 responses should include (or when applicable). The schema constraint and the spec text "Servers implementing this protocol version MUST include this field" apply to every result type, not only the three MRTR-capable types. Observed behavior Across both stdio and Streamable HTTP, the following pattern was observed: The three methods that do include are the three MRTR-capable types: , , . This is consistent with being set only from in . Additional context** As a possible reference point, the Python SDK appears to include at the model layer, where concrete subclasses declare as a field default. That avoids relying on individual handlers or dispatch paths to add the field. In the Go SDK, appears to be set only via (), which is invoked for the methods that go through the MRTR middleware. Other result types in do not appear to have a field.