build(deps): Bump github.com/modelcontextprotocol/go-sdk from 0.2.0 to 0.3.0

[dependabot]

Bumps github.com/modelcontextprotocol/go-sdk from 0.2.0 to 0.3.0.

Release notes

Sourced from github.com/modelcontextprotocol/go-sdk's releases.

Release v0.3.0

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](https://github.com/modelcontextprotocol/go-sdk/blob/HEAD/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.

... (truncated)

Commits

• f37e549 mcp: polish package doc for v0.3.0
• fb69971 mcp: cleanup transport after keepalive ping fails
• 9754a2a examples: add an everything example, and simplify hello
• c631641 mcp: check output schema type (#358)
• d16ce9c mcp/examples: moves middleware examples into example folder (#356)
• b891d95 mcp: example middleware wrapping ToolHandler (#351)
• 18c96d6 mcp: enforce input schema type "object" (#349)
• 4587941 mcp: add Request.GetExtra (#350)
• 42f419f mcp/examples: move elicitation example into example folder (#354)
• e3e8aaf mcp: align PromptHandler args with other handlers (#348)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)