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

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.

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.

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.

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)

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.

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

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?

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?

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.

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?

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.

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.

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

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

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

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

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.

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.

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.

@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.

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.

You are right, it will be harder over time as the SDKs mature. Worst case we would like to support the next level and long tail of languages.

I am planning to look at callbacks today and see what challenges they present. Its a good point and definitely should be addressed at an early stage like this.

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?

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/.

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.

@logiscapedev @LucaButBoring
Most of the languages are supporting sdk that run on the server like go, python etc - they dont run in browser yet without something like WASM/WASI/WAZero etc

A thin layer in browser that works with the server side clients could be a starting point.

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.

Its still separate - the only question is how do you want to implement it.

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.

We should also do the same - this implementation approach doesnt prevent as it will generate PHP code just like any other PHP app.

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.

Flutter/Dart would be a great bet IMO - it has a fantastic language toolchain, and there's a Rust bindings package that is very well supported (see: https://github.com/fzyzcjy/flutter_rust_bridge).

Thanks @pattobrien - Took a quick look and it appears it has got a lot of stars for such a niche area and is well received.

Do share any other feedback items. I am planning to put together a strawman before starting the work.

@tarunanand-dev amazing, glad the info could be of use!

I'm experienced in both Dart and building SDK generators as well (not so much the FFI/Rust bindings part); I'd be more than happy helping you get up to speed with "idiomatic" Dart and can help review the strawman and help with prototyping.

Added more examples for rust, typescript and python.

You can create a pr to introduce your work in the readme of rust-sdk repository.

If it can be develop as a integrated testing tool? If ok , that will be very nice.

That was the idea - if we can do it as part of the nightly build/pre-release package. Currently the system picks the latest 2 release and does a 2xNxN matrix test and for rust it just uses the current main as there is no release package yet.