One Rust Core, Many SDKs — A Proposal to Unify MCP’s Language Ecosystem

[tarunanand-dev]

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

Folks, as MCP’s language ecosystem expands, we’re spending more time re‑implementing the same deterministic‑state logic than shipping new ideas. I’d like us to flip that ratio by standardizing on a single, battle‑hardened Rust core (rust‑sdk) that owns the heavy workflow engine— sessions, peering, transport, serialization—while each language surface (Python, JS/TS, Go, etc.) stays 100 % idiomatic and lightweight. 

Rust gives us memory‑safe, no‑GC performance overhead, a stable FFI, and a proven path. The payoff is immediate: one quality, security and performance audit instead of five, feature parity across languages on day 1, and p99 latencies that drop from milliseconds to microseconds—without asking Python or JavaScript developers to learn Rust. 

In short, one deterministic engine, many friendly faces. We have built a V 0.1 Python SDK based on this architecture so that we write less boilerplate and innovate faster on the parts that matter.

Scope

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

[tarunanand-dev]

The following screenshot shows how the system looks like from a Python developer's perspective with the new proposal implemented.

The section on the right is the sse.rs example from the original rust sdk
The section on the left is the Python example written with the new python sdk with rust sdk as core.

[tarunanand-dev]

The developer workflows in both the languages (and future languages that are supported becomes consistent)

1. Create a transport
2. Create a ClientInfo
3. Serve/Initialize
4. List Tools
5. Call Tool

[jokemanfire]

Thank you for your work. Can I confirm if this proposal is to use Rust as the core and other languages as the outer API encapsulation? So, does Rust SDK need to separate its core from external APIs?

[tarunanand-dev]

Yes, the proposal is to use Rust as the core and other languages as the outer API encapsulation.

No Rust SDK doesnt need to change - only minimal changes are needed.

For reference, I was able to build Python SDK on top of your core Rust SDK without a single change in the Rust sdk. Cant say that for all the other languages no change will be needed but I would say its possible.

[jokemanfire]

I think this proposal is great, but Rust SDK is not yet fully mature and we are trying to release its first version.

[tarunanand-dev]

I will be submitting the Python bindings to the core rust sdk shortly. Kindly review it and you will see for yourself how it fits into the system.

Would be curious to know how we can help and make the Rust SDK mature as well whilst we build bindings.

[jokemanfire]

The cross system validation of Rust SDK, such as Windows and macOS, has not yet been confirmed, and the revised features of the new version are still being improved. There is still work to be done on the integration testing framework.

[tarunanand-dev]

Do you mean Windows and MacOS desktop ? I have been running the rust sdk on Macos for last 3 weeks without any issues.
Happy to understand what is pending on the integration testing and Windows/Linux support (I would imagine for servers Linux is a priority as well)

[jokemanfire]

Do you mean Windows and MacOS desktop ? I have been running the rust sdk on Macos for last 3 weeks without any issues. Happy to understand what is pending on the integration testing and Windows/Linux support (I would imagine for servers Linux is a priority as well)

I would like to incorporate the interaction between the service and client in the example into the integration testing first.

[tarunanand-dev]

I agree this is an important part. We can take this forward once I submit the typescript binding PR.

[4t145]

How to create mcp web server in other programming language?

I am curious about how to make a customized a mcp web server in other programing language by using rust SDK as a core? What if user want to add other service to web service router?

[tarunanand-dev]

The concept remains the same whether you are on the client or server, my upcoming PR is for the client but once you merge it I will do the same for the server as well.

I really liked how you build the "Service" with generics. A few areas are confusing like ServiceExt and Client_Info both using serve but nothing major.

Can you explain this "What if user want to add other service to web service router?" You mean expose another tool or resource or prompt?

[4t145]

1. ServiceExt is auto implemented for ClientInfo since ClientInfo implemented Service, so you can call serve on it.

2. People may want to intergrate other service with mcp web service. You can't call axum api in other languague I guess, and so do the other extension of rust sdk like reqwest., I guess?

[tarunanand-dev]

1. Thanks I will check it out.
2. If I undersand it yes, you can we are able to call from Python App -> Rust Bridge -> Core Rust SDK Axum api using reqwest.
   If your question is more of language bindings for server side rust sdk then I have not investigated that.

[tarunanand-dev]

I have submitted PR 172 for your review @jokemanfire @4t145

Kindly share your feedback.

[4t145]

That's a lot of work, I mean, there already are fine maintained python and JavaScript sdk, is it really worth to rebuild those upon rust sdk, which hasn't been widely use yet?

[tarunanand-dev]

Its a good question and the basic reason is to not reinvent the wheel. Currently each team of dozens of contributors is essentially building the same sdk in different languages. As opposed to one core sdk around which we could do just incremental work to build a language specific offering.

There are other benefits also about security, performance, audit, speed to market etc that I have outlined in my original proposal.

[jokemanfire]

I quite agree with this proposal because it is indeed wasteful to spend a lot of time implementing the same SDK in different languages, but what I am concerned about is

1. This job was only presented on Python, how does other languages support Rust.
2. The difficulty of this job is very high, which will result in a high maintenance workload for the rust sdk repository. I am not sure if the community has such a high level of active participation in maintenance.
3. This work actually goes beyond what the rust sdk warehouse plans to do, and I think it requires soliciting a lot of opinions from people who participate or use this warehouse

[tarunanand-dev]

Hello there,

1. Other languages have a similar approach (not same) - I am working on a Typescript binding and will submit a PR for that.
2. You are right that it requires maintenance but if you see that the rust code is mostly "pass through" and has to honour a few basic concepts. Most of the complex work still happens on the core sdk. We can come up with a roadmap and plan on how to do this in an incremental manner.
3. Please advise who can we solicit opinions from. I am happy to kickstart.

[jokemanfire]

You can initiate an ISSUS discussion in the Rust SDK repository to support more people to participate.

[tarunanand-dev]

Thanks, I just finished the Typescript bindings and will start an issue discussion in the Rust SDK repository

[tarunanand-dev]

I just submitted the PR 183 for Typescript bindings with example and README.md
This is initial works but demonstrates a fully working Typescript Client using the core rust sdk and talking to Rust server using axum.
modelcontextprotocol/rust-sdk#183

[tarunanand-dev]

Thanks @jokemanfire @4t145 for your feedback - to summarize

1. We should keep this in a separate repository and you will put a link in README
2. I will open an issue to get some feedback about the other languages support/bindings with rust so that there is some lineage.
3. I am happy to help contribute to the core rust sdk in parallel - I see several issues are open but happy to have a better test harness as well.
4. Lastly, I would request you to please introduce me to someone who can help me add this repository to the modelcontextprotocol main org.

[4t145]

We are just maintainer, we actually don't have any permission except merging code. You should contact some one in modelcontextprotocol organization: https://github.com/orgs/modelcontextprotocol/people

[olaservo]

Re: (4), the modelcontextprotocol org is reserved for official repos owned by the core team. My understanding of this proposal is that its a community-led project, so it seems best to keep this as a discussion topic with links to the repo for community visibility (along with whatever related discussions are happening in PRs, etc). At this stage it seems premature to add it to the official MCP org.

[tarunanand-dev]

Hello @olaservo Yes I am aware that org is for official repos. The idea as I mentioned below to @LucaButBoring is to first gain feedback using some popular languages and then get sdks out for languages that are not yet supported. Finally we would like to make these sdks the official sdks by reaching out to the org.

[LucaButBoring]

This is a cool proposal, and it's great to see examples in both Python and TS already. Regarding adoption and the long-term plans for this, I have a few questions (I don't expect any of these to have perfect answers, I'm just interested in discussing these):

1. With at least 7 official MCP language SDKs available and (at least in some capacity) in use already, how are you thinking about eventually bringing this into broader usage? I think it'd be a challenge to get existing projects to drop the language SDK they were already using and switch to this - but if this remains as a separate SDK indefinitely, that would fragment the ecosystem and complicate adoption at a very early stage in MCP's lifespan.
2. How much room would there be for implementing idiomatic interfaces on top of these bindings? From what I can tell, these wind up being largely constrained to the expressiveness of the FFI implementation - so I'm not sure how things like callbacks would work here, for example.
3. How do you envision this working for browser MCP clients? Under the approach being used here, the only path that I can see would be WASI - but using WASI on an entire client/server SDK with OS network calls would be a significant challenge to write bindings for (AFAIK every syscall becomes a separate WASI import that you need to register an implementation for).
4. On a similar note, if Go ever gets an official SDK, how would this be used (or not used) there? It's very common to disable cgo entirely in a project (and for good reason; though the performance overhead is far less now than when this was written). These kinds of runtime-specific considerations are relevant in all programming languages, but I think Go happens to be a particularly interesting example due to how cgo is handled.

---

Unrelated to the above, I found some libraries that may wind up being useful for this later on for other languages (was researching to do something exactly like this myself, actually):

• JVM: https://github.com/jni-rs/jni-rs (headers generated from Java sources; DLL needs to satisfy them)
• .NET: https://github.com/dotnet/ClangSharp (build a separate DLL and header file first; C# sources are generated)

[tarunanand-dev]

Thanks for your detailed response @LucaButBoring

1. I was wondering if we can extend first to language that are not yet supported. PHP has some good work from community but not yet supported and so do some other languages. Getting the community to rally around it is a huge effort but with a little help it could gain momentum first on not supported languages. For the currently supported languages I was thinking of a performance comparison starting with Python first - many of the popular Python libraries also use this concept for one reason alone - performance, and they continue to be idiomatic.
2. Majority of my time was spent on 2 things - making the APIs iditomatic and ergonomic. I didnt use callbacks - simple await and if you see line by line its a mirror in all 3 Rust, Typescript and Python - Would be keen to get your views on it as well.
3. Browser support is going to be a challenge (so is cgo is not go in golang for e.g.) I am looking at wasi preview 2 becoming more mature and wazero etc.
4. Golang community is already building a go sdk blessed by Google and others. One thing I find interesting is that by studying all these different sdks you can learn a lot and cross-pollinate ideas - Please propose any ideas to the rust sdk community itself.
5. Thanks - will take a look. I would be keen to connect and understand what else you are doing/any way to collaborate.

[tarunanand-dev]

@LucaButBoring

One benefit that people may not realize now but becomes a big challenge is the "integration tax" - you have M clients x N servers
In theory all the implementations should follow the spect to the T but that happens rarely. With a single core you reduce by an order of magnitude (but not eliminate completely) that overhead.

[LucaButBoring]

Getting the community to rally around it is a huge effort but with a little help it could gain momentum first on not supported languages.

I think this is sensible, but it also makes it harder over time to get the existing SDKs to migrate to it - "paying down" that integration tax will get harder as all of the SDKs continue to grow in isolation from each other.

Majority of my time was spent on 2 things - making the APIs iditomatic and ergonomic. I didnt use callbacks - simple await and if you see line by line its a mirror in all 3 Rust, Typescript and Python - Would be keen to get your views on it as well.

The reason I bring up callbacks is because of features that involve receiving data without being the request initiator, like sampling, (soon) elicitations, or even just server-side tool declarations. All of those are things that don't lend themselves very well to simple future/promise APIs, which is why they're typically exposed with callback interfaces.

Taking a look at your TS example, you only have client code generation for tool listing and tool calls, which fit an async API very well. I expect sampling to be more complicated.

Browser support is going to be a challenge (so is cgo is not go in golang for e.g.) I am looking at wasi preview 2 becoming more mature and wazero etc.

I wasn't aware of WASIp2 (only tried WASIp1) - that'd solve a lot of problems once it's more widely-adopted. Not sure how far out that'll be, but it does look extremely promising. wazero (and WASM in general) is a good idea worth exploring, but until WASIp2 is adopted, you'll be stuck with the problem of needing to implement language-specific code to polyfill a potentially very large number of syscalls.

I would be keen to connect and understand what else you are doing/any way to collaborate.

Same here, I hadn't started any implementation yet, just planning to do similar, though. I'm paying attention to this effort to see where it goes, first.

[heaths]

Have you taken a look at https://github.com/Azure/azure-sdk-for-rust? This is our official Azure SDK for Rust and @ronniegeraghty is working with partners to prioritize services. We do separate out those concepts of serialization, transport, etc. - as we do in all our languages' Azure SDKs - and even support arbitrary async runtimes, defaulting to tokio but will support any if you implement a couple of traits.

We don't have SSE support yet but it's on the backlog and just lower priority right now. My thinking was basically a Stream (or AsyncIterator if/when it's stabilized in std). We're always accepting of contributions as well.

BTW, there's also an official Azure SDK for Go: https://github.com/Azure/azure-sdk-for-go. Same underlying design: all our SDKs are designed to be idiomatic to the language, but consistent in the feature set and, to some degree, overall shape of clients.

[tarunanand-dev]

Hi @heaths @ronniegeraghty

Thanks for the pointer - I took a brief look at it and I like the concept of pluggable transport engines. Some other parts I am sure as the MCP spec evolves can be useful.

As I said earlier cross-pollination of ideas is good for the community. Would you be willing to consider language bindings to accelerate the azure sdk adoption?

[heaths]

Can you clarify?

Would you be willing to consider language bindings to accelerate the azure sdk adoption?

We have Azure SDKs in many other languages already; see https://azure.github.io/azure-sdk/releases/latest/.

[logiscapedev]

This is an interesting proposal as a standalone project, but I feel it's best to keep MCP as a protocol rather than a single unified platform.

In the case of my SDK for PHP a major priority was allowing the creation of MCP clients and servers in shared hosting environments, where the web developer may not necessarily have root access or privileges to the underlying server. This meant using pure PHP code and avoiding dependencies that aren't already provided by most hosting providers.

I'm sure there are other platforms where MCP would be useful, but may have specific requirements that would be overlooked in a unified project that tries to accommodate all platforms.

[LucaButBoring]

I think this ties into my previous comment on browser clients and Go with cgo disabled - I think there are answers to this (either WASM or simply don't leverage this in a few specific languages with more unique use cases), but that starts to get into some complicated trade-offs around integration patterns.

[tarunanand-dev]

@logiscape thanks for your feedback. As the author of the most popular community led PHP SDK your views are welcome.
The idea here was to cross-pollinate ideas from the community to improve the MCP ecosystem. As I mentioned in some of the earlier comments there are issues like performance, security, integration and time to market.

For e.g. as you mention that PHP client and server, but its not necessary that all servers be written in PHP or vice versa, in such a case we end up in testing all such combinations each with its own slight variations etc and as the protocol involves the complexity increases.

I believe we can keep the PHP idiomatic and ergonomic and still work with a language binding of rust.