This version of the SDK contains many bug fixes and new features. It is largely feature-complete, though see known limitations below. It also contains significant API changes from v0.2.0, detailed in the next section.
As outlined in #328, we have adjusted our target for v1.0.0 back to September, primarily because of the late API changes below. It is expected that the API in this release is largely finalized, though we may make additional changes between now and the first release candidate. If any of these changes are incompatible, we will document them loudly. If you have any feedback on the current API, please file an issue as soon as possible.
For the full list of changes, see the v0.3.0 milestone.
Thank you to all who tested the SDK, filed bugs, and contributed.
Breaking changes
Handlers
The largest source of API change is related to handlers: all Params arguments are now nested inside Request objects. This was necessary in order to transmit OAuth information, as well as additional HTTP headers (see #243). Since the ServerSession argument is infrequently needed, it is moved into the Session field of these request types.
So, for example, the PromptHandler type changes as follows:
- Old (v0.2.0):
func(context.Context, *ServerSession, *GetPromptParams) (*GetPromptResponse, error) - New (v0.3.0):
func(context.Context, *GetPromptRequest) (*GetPromptResponse, error).
Tools
Since handler signatures were changing anyway due to the above change, we used this opportunity to address a piece of feedback we'd received regarding the Tool binding APIs (#327): the use of generics was problematic for aspect-oriented programming, and complicates the common case of a simple tool.
The type parameters of CallToolParamsFor and CallToolResultFor are moved to additional (ordinary) input parameters and output parameters. So a typed tool functions changes as follows:
- Old (v0.2.0):
func(context.Context, *ServerSession, *CallToolParamsFor[In]) (*CallToolResultFor[Out], error) - New (v0.3.0):
func(context.Context, *CallToolRequest, In) (*CallToolResult, Out, error)
In the common case of structured input and output, typed tool handlers only need to interact with their input and output Go types:
func greet(_ context.Context, _ *CallToolRequest, args Args) (*CallToolResult, result, error) {
return nil, result{Message: "Hi "+args.Name}, nil
}In order to enable the wrapping of tool handlers, we added a new constructor that exposes the modified Tool and ToolHandler that are created when binding a tool to a tool function:
// ToolFor returns a shallow copy of t and a ToolHandler that wraps h.
func ToolFor[In, Out any](t *Tool, h ToolHandlerFor[In, Out]) (*Tool, ToolHandler)So mcp.AddTool is just a shortcut for server.AddTool(ToolFor(...)).
New jsonschema package
The jsonschema package is moved out of the SDK, into github.com/google/jsonschema-go, so that it may be reused by other projects without the 'go-sdk' import path.
Transports
Since transports initialize their connection state during the call to Connect, we realized that there is no need to have both transport types and transport options: the transport types should just be open structs (#272).
type CommandTransport struct {
Command *exec.Cmd
}For now, the XXXOptions and NewXXX symbols are deprecated but not yet removed. However, they will be removed prior to the v1.0.0 release (#305).
Concurrency model
As described in #26, the SDK now has a formal concurrency model for handling requests: notifications are handled synchronously, and all calls are handled asynchronously. We believe this is the least error prone behavior.
Known limitations
The following outstanding issues may affect the production suitability of this SDK. We will address all before v1.0.0:
- Potential memory leaks in HTTP transports: #190 could lead to memory issues in the case of slow clients.
- Lack of client-side oauth support: See #255.
New Features
- Server side oauth support: support is added for server-side oauth (#237).
- Stateless streamable transport: support is added for 'stateless' streamable sessions, which are one way to implement distributable MCP servers (see #148 for details).
- MCP Features: resource subscriptions, elicitations. Support is added for a couple missing MCP features: resource subscriptions and elicitations.
New Contributors
Thank you to our new contributors!
@prattmic, @viddrobnic, @nsega, @qt-luigi, @A11Might, @cr2007, @ln-12, @wkoszek, @zchee, @francistm, @slimslenderslacks, @winterfx, @davidleitw, @aryannr97, @krtkvrm, @RileyNorton, @KamdynS, @MrGossett, @2bitburrito, @manmartgarc, @mattlgy, @yasomaru, @h9jiang
Full Changelog: v0.2.0...v0.3.0
