Proposal: official support for modelcontextprotocol/go-sdk

[jpmcb]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

There are a number of discussions around Go sdks for MCP:

• https://github.com/orgs/modelcontextprotocol/discussions/85
• https://github.com/orgs/modelcontextprotocol/discussions/81
• https://github.com/orgs/modelcontextprotocol/discussions/78
• https://github.com/orgs/modelcontextprotocol/discussions/19
• https://github.com/orgs/modelcontextprotocol/discussions/153

Most of these are around custom, third party sdks that have seen variable adoption and maintenance. I've even considered writing my own since there is not an official opinion from the upstream protocol.

But, now, with the addition of the C# sdk, the Rust sdk, and a Kotlin sdk, it's clear there needs to be an officially supported one for Go.

Proposal: create an official modelcontextprotocol/go-sdk

This should be a sole sdk that can be pulled in through a go module:

go get github.com/modelcontextprotocol/go-sdk

and which is maintained by the broader community. This would then create the defacto standard for a Go sdk and unify the ecosystem which is rather fractured right now.

https://github.com/mark3labs/mcp-go seems to be the most up to date and with the most stars: maybe we consider forking it or asking @mark3labs if they'd like to donate it. Otherwise, we would expand this proposal to include the shape of such a first party sdk.

I would also like to volunteer as a maintainer and/or Go evangelist to make this happen: a fractured ecosystem is something that Go has faced in the past. It's great that it's so easy to pull different modules off of GitHub, but an official opinion will help drive broader adoption in Go.

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[ChrisJBurns]

Was about to raise the same discussion topic, beat me to it!

[gramidt]

@jpmcb this is a great idea. I would love to volunteer help make this a reality and to keep it maintained.

[nickemma]

Add me up

[edricgalentino]

I'd also be happy to

[dblooman]

+1

[rashm1n]

+1

[codefromthecrypt]

+1

[kyleconroy]

I maintain an implementation (https://github.com/riza-io/mcp-go) and would love to archive it in favor of an official SDK.

[MegaGrindStone]

I also maintain a Go implementation of MCP (https://github.com/MegaGrindStone/go-mcp) and would similarly be happy to archive my repository in favor of an official SDK. Looking forward to contributing to or supporting the official implementation if there are opportunities to do so.

[wfernandes]

@jpmcb thanks for starting this initiative. I'd love to contribute some time to help learn and maintain this.

[elviskahoro]

+1

[joobisb]

@jpmcb this is great! I would love to get involved as well

[pgmstream]

I too would like to voluteer time and effort in this endeavor. Please let me know how I can be of assistance.

[baiyutang]

+1, I can do somthing for this.

[GhostScientist]

@jpmcb great proposal! I'd love to help however I can. 👍

[manusa]

I'm making an extensive use of https://github.com/mark3labs/mcp-go (plus added a few fixes to that code-base) to build MCP servers for containers.

I'd be happy to help out in any way I can too.

[baditaflorin]

Would love this +1

[NameHaibinZhang]

Would love this +1

[zhengkunwang223]

Would love this +1

[Abdulrahman-02]

up
Can we port it from the TypeScript SDK in the same way they ported the TypeScript compiler?

[jpmcb]

It wouldn't be exactly the same as what Microsoft is doing to port the Typescript compiler since the target of a Golang MCP server / client is a binary.

We want a purpose built SDK for Go that fulfills the MCP spec and is officially supported in the modelcontextprotocol GitHub org.

[JAORMX]

Has anybody contacted mark3 labs yet? Would be great to get this kicked off

[ibakshay]

Seems like mark3labs is on vacation until the end of this week. - mark3labs/mcp-go#127

[pavelanni]

@ttys3 I used mcp-golang in my server before I switched to mcp-go. I hit a bug in their implementation of JSON-RPC: they use int64 as RequestId while the specification also allows a string and a null (https://github.com/metoro-io/mcp-golang/blob/6f6550eb056f607bda13a908f21bec15cb148521/transport/types.go#L10). I opened an issue, forked and fixed it in my repo, but got no response from them. The whole project is not very active: the last commit was today, but before that, the previous commit was on January 28.

[ttys3]

@ttys3 I used mcp-golang in my server before I switched to mcp-go. I hit a bug in their implementation of JSON-RPC: they use int64 as RequestId while the specification also allows a string and a null (metoro-io/mcp-golang@6f6550e/transport/types.go#L10). I opened an issue, forked and fixed it in my repo, but got no response from them. The whole project is not very active: the last commit was today, but before that, the previous commit was on January 28.

5 hours ago they just merged a PR. metoro-io/mcp-golang#85

thanks for mentioning, I've got your issue: metoro-io/mcp-golang#79

Their development may not be as active as mark3 labs, but please take a look at the repository code and make a comparison. Additionally, they are under the MIT license, which means if the community is willing, it is entirely possible to fork it for the development of the official go-sdk.

[hl540]

https://github.com/mark3labs/mcp-go
At first I thought it was a good idea to declare Schema in Tag, but too many declarations in tag can lead to messy code and poor maintainability. It is more inclined to use the with method declaration, which is convenient and intuitive.

[ttys3]

mark3labs/mcp-go At first I thought it was a good idea to declare Schema in Tag, but too many declarations in tag can lead to messy code and poor maintainability. It is more inclined to use the with method declaration, which is convenient and intuitive.

Yes, both methods have their pros and cons. Automatic conversion may have some special cases that require special handling. However, the manual method requires people to synchronize and maintain these models.

[groot-guo]

+1, mcp-go

[amren1254]

+1, mcp-go.

[ropon]

什么时候能实现呢

[JeffreyRichter]

I have also been working on a Go MCP SDK. And I'd be happy to contribute my work to this effort. My code is currently here. A lot of this is working but the transport still needs some work.

This SDK is goroutine safe, allowing multiple methods to be processed in parallel safely. It also supports method cancellation, RPC batches, message validation & error responses, and offers a synchronous programming model when a service needs to make asynchronous requests back to the client.

Consumers of it would have to write NO CODE to get all of the features above.
It also provides default (but overridable) implementations for the follow MCP Server methods (an SDK consumer would have to write NO CODE to get all of these working):

ping
logging/setLevel
notifications/initialized
notifications/cancelled
notifications/roots/list_changed
completion/complete
prompts/list
tools/list
resources/list
resources/templates/list
resources/subscribe
resources/unsubscribe.

Consumers only need to implement the 'initialize' method, with optional methods including 'prompts/get', 'resources/read', 'tools/call', and 'notifications/progress' depending on their needs.

[SerkanSipahi]

+1, mcp-go

[gatuin]

Be great if there was support for authentication as part of the SDK.

[Mehdi-Bl]

Yes go deserve more love and official SDK would consolidate the efforts.

[edoger]

After discussing this for so long, where is our repository? I have no place to contribute!

[olaservo]

Hi @edoger , https://github.com/orgs/modelcontextprotocol/discussions/224#discussioncomment-12730162 is still in the works and I'm expecting updates will be shared in some form in the near future.

[songhobby]

+1
I'd love to contribute.

[nagstler]

This is Great!

I’ve built a Ruby SDK for MCP that’s modular and extensible, would love to get it listed as an official SDK.

You can check it out here: https://github.com/nagstler/mcp_on_ruby

Raised a discussion thread here:

https://github.com/orgs/modelcontextprotocol/discussions/312#discussion-8220655

[alok87]

by when are we thinking it will get released?

we want to use the official go SDK that comes with “Streamable HTTP” can we contribute and help?

[stuckinforloop]

+1

[davidli2010]

It's been a month. When shall we start?

[olaservo]

Hi @davidli2010 , https://github.com/orgs/modelcontextprotocol/discussions/224#discussioncomment-12730162 is still in the works and I'm expecting updates will be shared as an announcement here once its made public.

[zchee]

The Go tools team has started implementing the MCP protocol from scratch.

• https://github.com/golang/tools/tree/master/internal/mcp
  • depends: https://github.com/golang/tools/tree/master/internal/jsonrpc2_v2

Commits:

• internal/mcp: an MCP SDK prototype · golang/tools@cc6bc88
  • gerrit: internal/mcp: an MCP SDK prototype (667036) · Gerrit Code Review
• internal/mcp: add batching support · golang/tools@357c3da
  • gerrit: internal/mcp: add batching support (667295) · Gerrit Code Review

---

It's still in its early phase, but I think few people have the technical expertise to surpass it in the term of architecture layer performance¹, security, and code readability. However, it is developed in the internal directory, so it cannot be imported from outside.
So, how about creating a repository that copies internal mcp and jsonrpc_v2 packages from upstream², like the one Russ Cox copied for 9fans/acme-lsp at 9fans/go-lsp-internal?

Footnotes

1. The Go tools team barely uses any third-party packages, such as an optimized json parsing package, etc. So "terms of architectural " ↩

2. Automated with GitHub Actions or something ↩

[findleyr]

@jba I think @jpmcb is saying that we (I) haven't been forthcoming about the design or implementation, and I think that's very fair. My post on Friday was an attempt to start sharing what we've learned, but much more is needed. We need to open up those conversations as soon as possible. My apologies that it has taken so long.

I think jba's point is that slog is actually an example of an open design and discussion process on the Go team. We can do that here too. But I'll also note that I'm sure a lot of pre-work happened before the slog discussion started; this is the pre-work that I was trying to do with the prototype.

[anuraaga]

Hi @findleyr @jba - sorry if this is not a good place for this sort of question but what would be the way to collaborate on the MCP work in x/tools? I see the links to an issue/discussion for log/slog package but couldn't find anything similar for MCP - it sounds like we're currently in the pre-steps for that, but it would still be great if we could get discussions going. The context is I have been working on context propagation across MCP and want to follow along to see if the Go implementation can support it well in the future, or even help with implementation where possible.

As an example, I noticed the schema is generated from the JSON schema, but unfortunately JSON schema can't handle the type inheritance of the ground-truth typescript schema, and consequently misses the _meta field in requests used for propagation (the workaround in the official SDKs is to use AI to generate from the Typescript schema). Anyways going too deep on that is undoubtedly not in scope for this repo hence the question of what would be a good way to have such discussions.

Thanks!

[codefromthecrypt]

@anuraaga thanks for bringing this up. I think the point you've made about missing _meta impacts more than trace propagation. It will also interfere with progress which uses this as well

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "some_method",
  "params": {
    "_meta": {
      "progressToken": "abc123"
    }
  }
}

[findleyr]

@anuraaga we're going to start a discussion as soon as we possibly can (we're awaiting an approval for our discussion draft of this week):
https://go.googlesource.com/tools/+/refs/heads/master/internal/mcp/design/design.md

Thanks for bringing that up about Meta; that's exactly the type of thing we'd want to discuss (and the reason why we think it's important to start with a public discussion). Our generation logic already handles a fair bit of customization, so we may need to override its default treatment of _meta.

[codefromthecrypt]

hope this summarization of the concern helps. that said, as you mentioned there's a non-schema way out also which is to adjust a generator modelcontextprotocol/modelcontextprotocol#414 (comment)

[olaservo]

For anyone who missed it from the deeper thread, the new discussion for next steps on the official Go SDK design has kicked off here: https://github.com/orgs/modelcontextprotocol/discussions/364

[pperesbr]

+1