MCP Go SDK

When a protocol picks up community SDKs faster than it can ratify its own, the arrival of an official implementation is the real signal that it has stabilized. This SDK is that signal for MCP in the Go ecosystem: it is the canonical reference, maintained in collaboration with Google, and it openly credits the third-party SDKs that came before it. The design choice that matters most is that you describe tools as plain Go types, and the schema falls out of the type system rather than being hand-written and kept in sync by hand.

What Sets It Apart

• Tool input and output schemas are inferred from your Go structs through generics and jsonschema struct tags, so the wire contract can't silently drift from the code that serves it.
• The codebase is split into focused packages — mcp for the client/server APIs, jsonrpc for writing custom transports, and auth/oauthex for OAuth and ProtectedResourceMetadata — so OAuth concerns stay out of your tool logic.
• Transports cover the realistic deployment shapes: StdioTransport and CommandTransport for local subprocesses, streamable-HTTP and SSE for networked servers, and an in-memory transport for fast tests without spawning processes.
• Specification support is versioned explicitly, with newer releases tracking the 2025-11-25 spec and earlier ones mapping to 2025-06-18, so you can pin behavior to a known spec revision.

Where It Fits

The SDK does not pretend to be the only option. The README notes that several third-party Go MCP SDKs "inspired the development and design of this official SDK, and continue to be viable alternatives, notably mcp-go," and thanks the authors of mcp-golang and go-mcp. The practical difference is governance: this one is the protocol authors' own reference and moves in lockstep with the spec, while the community SDKs predate it and have their own maturity and API conventions.

Who It's For

Great fit if you are writing MCP servers or clients in Go and want the schema, transport, and OAuth plumbing to be the official, spec-tracked version with type safety baked in. Look elsewhere if your service already runs on an established community SDK and a migration would buy you little, or if you need a language other than Go — in which case the protocol's SDKs in other languages are the better starting point.