modelcontextprotocol/go-sdk
Watch
1
0
Fork
You've already forked go-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
go-sdk/docs/rough_edges.md
Robert Findley 623780125c
 mcp: support SSE polling and server disconnects (SEP-1699) (#663) 
This CL implements support for SEP-1699, adding the following new API:

- Event.Retry corresponds to the 'retry' field of a server sent event.
This is used to signal client retry behavior.
- RequestExtra.CloseStream is set by the streamable transport to allow
closing a stream.

The streamable server transport is updated to set CloseStream for calls,
allowing server operations or middleware to close the underlying stream.
If the configured 'reconnectAfter' delay is set, a 'retry' message is
sent prior to terminating the stream.

The streamable client transport is updated to read the configured delay.

Fixes #630
2025-12-01 16:21:37 -05:00

1.4 KiB
Raw Blame History

Rough edges: API decisions to reconsider for v2

This file collects a list of API oversights or rough edges that we've uncovered post v1.0.0, along with their current workarounds. These issues can't be addressed without breaking backward compatibility, but we'll revisit them for v2.

  • EventStore.Open is unnecessary. This was an artifact of an earlier version of the SDK where event persistence and delivery were combined.

    Workaround: Open may be implemented as a no-op.

  • Event need not have been exported: it's an implementation detail of the SSE and streamable transports. Also the 'Name' field is a misnomer: it should be 'event'.

  • Enforcing valid tool names: with SEP-986 landing after the SDK was at v1, we missed an opportunity to panic on invalid tool names. Instead, we have to simply produce an error log. In v2, we should panic.

  • Inconsistent naming.

    • ResourceUpdatedNotificationsParams should probably have just been ResourceUpdatedParams, as we don't include the word 'notification' in other notification param types.
    • Similarly, ProgressNotificationParams should probably have been ProgressParams.

  • AudioContent.MarshalJSON should have had a pointer receiver, to be consistent with other content types.