MCP Go
Author: mark3labs
Description: A Go implementation/SDK for the Model Context Protocol (MCP) to build MCP servers that expose Resources, Tools (including task-augmented async tools), and Prompts to LLM applications. Supports stdio, SSE, and streamable-HTTP transports; session management (per-client state, per-session tools, tool filtering, notifications); request hooks and tool-handler middleware (including recovery); optional auto-completions for prompt and resource-template arguments. Implements MCP spec 2025-11-25 with backward compatibility for 2025-06-18, 2025-03-26, and 2024-11-05. Install via `go get github.com/mark3labs/mcp-go`.
Stars: 8.3k
Forks: 785
License: MIT License
Category: Open Source
Overview
Installation
go get github.com/mark3labs/mcp-gogo generate ./...hello_world
Say hello to someone using a provided name argument
calculate
Perform basic arithmetic operations (add, subtract, multiply, divide) on two numbers
process_batch
Process an array of items asynchronously as a task-augmented tool (TaskSupportRequired)
analyze_data
Analyze provided data; can run synchronously or asynchronously as an optional task tool (TaskSupportOptional)
http_request
Make an HTTP request to an external API using method, url, and optional body
user_data
Access user-specific data as a per-session tool available only to a specific client session
session_aware
Return a response that depends on the active client session retrieved from context
FAQs
How do I migrate an existing MCP Go server to the official Go SDK, and what are the main API differences?
Migration involves updating imports from github.com/mark3labs/mcp-go to github.com/modelcontextprotocol/go-sdk and adjusting handler signatures. The official SDK uses different method names for tool registration and modified context propagation. Transport setup differs, particularly for stdio initialization. Handler logic typically transfers directly since both follow JSON-RPC transport, but review the official migration guide for breaking changes.
How do I configure MCP Go to support both stdio and Streamable HTTP transports in the same server?
MCP Go requires you to choose one transport per server instance at startup using either ServeStdio or the SSE/HTTP server call. To support both transports simultaneously, run two separate server instances with the same handler logic but different transport configurations, allowing clients to connect via their preferred protocol without code duplication in your tool implementations.
How does MCP Go's per-session tool filtering and session management work for multi-tenant deployments?
MCP Go maintains separate state containers per client, enabling session-scoped tool registration rather than global server registration. Per-session filtering restricts tool visibility based on connection context, authorization, or tenant identifiers. This prevents data leakage by ensuring one client cannot invoke tools registered exclusively for another client's session, even when sharing the same server process.
How do I add middleware, request hooks, and error recovery to MCP Go tool handlers?
MCP Go includes built-in panic recovery middleware for tool handlers. For request hooks, use the SDK's request hook registration to intercept calls before execution. Add custom middleware by wrapping handler functions with logging, authentication, or validation logic before passing to AddTool. Check mark3labs repository examples for hook patterns and middleware composition.
How can I implement connection pooling to improve MCP server performance?
MCP Go lacks built-in connection pooling, so implement it using standard Go patterns. Initialize a shared database pool in your server's main function using drivers like pgxpool for PostgreSQL or sqlx, then pass pool references to tool handlers. Configure max connections based on expected concurrent MCP client sessions, typically ten to twenty connections.
What are the risks of using a solo-maintained SDK like MCP Go in production, and how can I mitigate dependency issues?
Solo-maintained projects risk abandonment, delayed security patches, and breaking changes without migration paths. Mitigate by pinning exact versions in go.mod, maintaining a fork for critical fixes, writing adapter layers to isolate SDK calls, and monitoring the repository for activity drops. Consider contributing patches upstream or budgeting engineering time for potential migration to the official SDK if maintenance ceases.