mark3labs/mcp-go: A Go SDK for Building MCP Servers

The gap mcp-go fills for Go services

MCP defines a wire protocol between an LLM application and a process that supplies data or actions. Implementing that protocol by hand means writing JSON-RPC framing, capability negotiation, tool schema serialisation and request dispatch. mcp-go exists so a Go developer does not have to. The README describes it as high-level and easy to use, and the opening example is roughly twenty lines: create a server and register one tool named hello_world. The intended audience is Go engineers who already have a service, a database client or an internal API and want an LLM client to call into it. The README frames MCP servers as roughly analogous to web APIs, with Resources compared to GET endpoints, Tools to POST endpoints, and Prompts as reusable interaction templates. That framing is the clearest statement of scope: the README is centred on building servers, not on being a general purpose agent framework.

What the server API actually does

The central type is created by server.NewMCPServer, which takes a server name, a version string and a variadic list of options. Two options appear in the README examples: server.WithToolCapabilities(false) and server.WithRecovery(). The first is a capability flag passed at construction; the second installs panic recovery, which matters because a tool handler that panics would otherwise take down the process serving the client. Tools are declared with mcp.NewTool and a chain of option functions. mcp.WithDescription sets the tool description, mcp.WithString declares a string parameter, mcp.Required marks a parameter mandatory, and mcp.Description documents an individual parameter. Registration is a single call, s.AddTool(tool, handler).

Getting a server running: install and first launch

Installation is a single Go module fetch: go get github.com/mark3labs/mcp-go. The go.mod file declares go 1.25.5, so check your toolchain against that. A minimal server needs two imports, github.com/mark3labs/mcp-go/mcp and github.com/mark3labs/mcp-go/server. Construct the server with server.NewMCPServer("Demo", "1.0.0", server.WithToolCapabilities(false)), register at least one tool, then call server.ServeStdio(s) and print the returned error. The README's calculator example adds server.WithRecovery() alongside the tool capability option. The README also has a Transports section in its table of contents, and it lists OAuth Protected Resource Metadata, session management, request hooks and tool handler middleware as extras. Treat the table of contents as a map of what exists, not as documentation of how to configure it.

Sessions, hooks and middleware as extension points

The README's extras list is where the library stops being a thin wrapper. Session management is broken into basic session handling, per-session tools, tool filtering and working with context. Per-session tools and tool filtering together imply that the tool set a client sees can vary by connection rather than being fixed at startup, which is a meaningful design difference from a static registry. Request hooks and tool handler middleware give two separate interception points: hooks at the request level, middleware around the tool handler. The distinction matters if you need to log every incoming request versus wrap only tool execution. The Regenerating Server Code entry in the table of contents suggests some part of the server surface is generated, which is relevant to anyone who plans to fork or patch the library. If you intend to depend on per-session tool filtering, read the README's Per-Session Tools and Tool Filtering sections and the source first.

Protocol version coverage and the completeness caveat

The README states that mcp-go implements MCP specification version 2025-11-25, with backward compatibility for 2025-06-18, 2025-03-26 and 2024-11-05. Four supported revisions is a concrete claim and a useful one: it means an older client is not automatically out of scope. The same README undercuts the completeness claim in two places. The key features list says the project aims to provide a full implementation of the core MCP specification, with the word aims carrying an explicit footnote that reads emphasis on aims. A warning block then states that MCP Go is under active development, as is the MCP specification itself, and that core features are working but some advanced capabilities are still in progress. That is unusually honest for a README and it should shape how you evaluate the project. The release history is consistent with the warning: v1.3.0 on 2026-10-14, v1.4.0 on 2026-10-26 and v1.5.0 on 2026-10-30, so minor releases are still arriving every week or two. If your integration depends on a capability the README does not demonstrate, assume it may be one of the advanced features still in progress.

Where mcp-go is the wrong choice

The most obvious mismatch is direction. Everything shown here is server construction: NewMCPServer, AddTool, ServeStdio. If you are building the LLM application side and need to connect out to third-party MCP servers, note that the README is centred on servers, although the repository has a client/ package and examples such as simple_client. A second mismatch is language. If your existing tooling is Python or TypeScript, adopting mcp-go means running a separate Go binary alongside it and wiring that binary into the client, which adds a process boundary and a deployment artifact. A third case is a throwaway script. The library's value is in protocol handling and session management; for a single tool invoked once, the boilerplate of a server, a tool declaration and a handler may cost more than it saves. Finally, the README's own warning is the strongest reason to hesitate: if your requirement list includes a capability that is not in the examples, you cannot conclude from the README that it is implemented.

How this differs from a hand-rolled JSON-RPC layer

The alternative to mcp-go is not another Go MCP library so much as writing the protocol layer yourself against the MCP specification. The difference in approach is concrete. Hand-rolling means you own the JSON-RPC envelope, the initialise handshake, capability advertisement, tool schema generation and dispatch by tool name. With mcp-go, schema generation comes from the option chain on mcp.NewTool, and dispatch comes from s.AddTool mapping a name to a handler. The trade-off is that you inherit the library's opinions about handler signatures and result construction. If you need a transport or a protocol revision the library does not cover, you are either contributing upstream or bypassing the library. For a standard stdio server exposing a handful of tools, the library removes a category of work that has nothing to do with your actual product. For anything unusual at the protocol level, that same abstraction becomes the thing you fight.

Licence, maintenance and upgrade cost

mcp-go is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement. This is not legal advice; read the LICENSE file in the repository if the distinction matters to your organisation. On maintenance, the release cadence is rapid: v1.3.0, v1.4.0 and v1.5.0 between 2026-10-14 and 2026-10-30. Post-1.0.0 the expectation is that the exported API stabilises, but the README's statement that the MCP specification itself is under active development means protocol-level changes will keep arriving regardless of the library's own version policy. Practically, pin your module version in go.mod rather than tracking main, and read the release notes before bumping, because a specification revision can change behaviour even when the Go API looks unchanged.

Editorial conclusion

Adopt mcp-go if you are writing a Go process that must expose tools or resources to an MCP client and you want the protocol framing handled for you. Do not adopt it if you need a client-side SDK in another language, or if you require every capability in the MCP specification to be present today; the README states that some advanced capabilities are still in progress. Before committing, verify that the spec version you target matches the versions listed in the README, and check whether the transport you need is implemented rather than planned.

Frequently asked questions

Official sources

1. License: MIT
2. mark3labs/mcp-go on GitHub
3. Project website
4. README
5. Releases