modelcontextprotocol/go-sdk: the official Go SDK for MCP, and where it stops short
The official Go SDK for Model Context Protocol servers and clients. Maintained in collaboration with Google.
At a glance
- What is it?
- The repository ships an MCP client and server library across four importable packages, with a documented spec compatibility table and a deprecation window for roots, sampling and logging. The core judgement: adopt it if you need spec-tracked protocol behaviour and stdio or custom transports, not if you want a batteries-included tool router.
- Who is it for?
- Adopt modelcontextprotocol/go-sdk if you are building an MCP server or client in Go and want the protocol version table in the README to govern which spec revisions you speak, or if you need to write a transport against the jsonrpc package. Do not adopt it if you expect the SDK to route, validate or orchestrate tools for you; the README shows mcp.AddTool and session.CallTool and nothing above them.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: a Go SDK that tracks the MCP spec revision
Most Go MCP libraries existed before an official one did, and the README says so directly in its acknowledgements, naming mcp-go, mcp-golang and go-mcp as inspirations and continuing alternatives. What the official SDK adds is a version compatibility table that ties SDK releases to MCP specification dates. The table lists v1.7.0 and later as supporting 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05, and it footnotes the older rows with qualifications: client side OAuth was experimental in v1.4.0 through v1.6.1, and v1.2.0 through v1.3.1 had only partial support for 2025-11-25, with client side OAuth and Sampling with tools unavailable. That table is the product. If you are writing a server that has to negotiate with clients built against different spec revisions, the question 'which SDK version do I pin' has a written answer here rather than an inferred one. The audience is Go engineers building MCP servers or clients, plus anyone writing a transport, which the README addresses with a separate jsonrpc package.
Four packages, and the one you probably will not import
The repository splits into mcp, jsonrpc, auth and oauthex. The mcp package holds the primary APIs for constructing clients and servers. The jsonrpc package is explicitly for users implementing their own transports, which tells you the transport boundary is a supported extension point rather than an internal detail. The auth package provides primitives for OAuth support, and oauthex adds protocol extensions such as ProtectedResourceMetadata. Note the phrasing in the README: auth provides 'some primitives', not a complete OAuth implementation. If your server needs to issue and validate tokens end to end, you are assembling that yourself from the primitives plus whatever OAuth library you already use. The docs directory is described as containing feature documentation that maps the MCP spec onto these packages, which is where the README sends you for anything beyond the two snippets it shows.
The mechanism: a server, a tool registration, and a transport interface
The README's server example is compact enough to describe exactly. You construct an mcp.Server with mcp.NewServer, passing an mcp.Implementation carrying a name and version. You register a tool with mcp.AddTool, which takes the server, an mcp.Tool with Name and Description, and a handler function. The handler signature is the interesting part: it receives a context, a *mcp.CallToolRequest, and a typed input struct, and returns a *mcp.CallToolResult, a typed output struct, and an error. The input and output structs carry struct tags, both json and jsonschema, so the schema for the tool's arguments is derived from the Go type. That is the SDK's central design decision: the tool schema is a consequence of the handler's parameter type rather than a separate declaration you keep in sync by hand. The handler returns nil for the CallToolResult in the example and a populated Output struct, which suggests the SDK fills in the result envelope from the typed output. Finally you call server.Run with an mcp.Transport, in the example an mcp.StdioTransport, and it blocks until the client disconnects.
The client side, and what CommandTransport implies about process ownership
The client example constructs an mcp.Client with mcp.NewClient, again with an Implementation, then connects using an mcp.CommandTransport wrapping an exec.Command. So the SDK's built-in client transport for local servers is process spawning: you hand it a command, it starts the process, and it speaks MCP over that process's stdin and stdout. client.Connect returns a session and an error, and the session is closed with defer session.Close(). Tool invocation goes through session.CallTool with an mcp.CallToolParams holding a Name and an Arguments map of string to any. The result has an IsError flag that you check separately from the error return, and content is a slice you type-assert, as in the example's res.Content entry cast to *mcp.TextContent to read .Text. Two things follow from this. First, error handling is two-layered: transport and protocol failures come back as an error, while a tool that ran and failed comes back as IsError on a successful call. Second, the type assertion on content means you are responsible for handling content kinds other than text; the README shows only the text case.
Running it: the imports, the transport, and where the examples live
Getting started is a go get of github.com/modelcontextprotocol/go-sdk, then importing github.com/modelcontextprotocol/go-sdk/mcp. The server needs mcp.NewServer, mcp.AddTool and server.Run with &mcp.StdioTransport{}. The client needs mcp.NewClient, client.Connect with &mcp.CommandTransport{Command: exec.Command("myserver")}, session.CallTool and session.Close. There is no configuration file and no environment variable in the material provided; the Implementation struct's Name and Version fields are the only identifiers the README sets, and the transport choice is made in Go code. The README points at the examples directory for more example clients and servers, and at the docs directory for feature documentation. If you want to see a non-stdio transport, that is where to look, because the README itself only demonstrates stdio on the server side and command spawning on the client side.
The deprecation clock on roots, sampling and logging
This is the most consequential thing in the README and it is easy to skim past. The roots, sampling and logging features are deprecated as of protocol version 2026-07-28 by SEP-2577. The SDK continues to support them for compatibility during a deprecation window of at least twelve months, and the README says migration guidance lives in the individual feature documentation. If your server implements sampling, meaning it asks the client's model to generate something, that capability is on a countdown. The window is described as at least twelve months, which is a floor rather than a commitment, so the practical planning assumption is that the deprecation window may be longer but not shorter. Anyone starting a new server today should treat these three features as things to avoid designing around, and anyone maintaining an existing one should read the per-feature migration guidance before the window closes rather than after.
Where it is the wrong tool, and how mcp-go differs
The README is candid that third party SDKs remain viable alternatives, and names mcp-go first. The difference in approach visible from this material is governance and spec tracking rather than feature surface. mcp-go predates the official SDK and, per the acknowledgements, influenced its design; the official SDK's distinguishing property is the compatibility table binding releases to spec revisions and the maintenance commitment implied by 'maintained in collaboration with Google' and the modelcontextprotocol organisation. That matters if you are shipping a server that must interoperate with clients across spec versions, and matters much less if you are prototyping against a single client. Where the official SDK is the wrong tool: if you want an opinionated framework that handles routing, middleware or tool discovery for you, neither the README nor the examples shown here suggest that layer exists. mcp.AddTool registers one tool with one handler. There is also the licence split to read carefully, covered below, and the fact that the repository's licence is reported as NOASSERTION at the repository level even though the README states Apache 2.0 for new contributions with existing code under MIT.
Maintenance cost, licence split, and the pre-release cadence
Recent releases show v1.8.0-pre.2 and v1.8.0-pre.1 published on the same day, 2026-09-04, with v1.7.0 the last stable release on 2026-07-28. Two pre-releases in one day is normal for a project cutting a minor version, but it means the pre-release line is not something to pin in production; v1.7.0 is the stable target and is also the version where the current spec support row begins. On the licence: the README states Apache 2.0 for new contributions with existing code under MIT, and directs you to the LICENSE file for details. That is a split-licence repository, and the practical consequence is that which terms apply can depend on which files you are using and how you are using them. This is not legal advice; if you are redistributing or vendoring the SDK, read LICENSE and get your own answer. The upgrade cost is bounded by the compatibility table: moving from v1.6.1 to v1.7.0 changes your supported spec set, and the footnote markers on older rows indicate that some capabilities arrived experimentally before they were settled. New releases target only supported Go versions, so a Go upgrade may be forced on you by an SDK upgrade.
Editorial conclusion
Adopt modelcontextprotocol/go-sdk if you are building an MCP server or client in Go and want the protocol version table in the README to govern which spec revisions you speak, or if you need to write a transport against the jsonrpc package. Do not adopt it if you expect the SDK to route, validate or orchestrate tools for you; the README shows mcp.AddTool and session.CallTool and nothing above them. Before committing, verify three things in the repository itself: that v1.7.0 or later is the version you pin, that the LICENSE file matches your obligations given the Apache 2.0 plus MIT split, and that none of your server's features depend on roots, sampling or logging beyond the twelve-month deprecation window.
Community notes