Features vs Crates and modularity (was: Learn or combine efforts from mcp-daemon?)

[Hendler]

For my own edification I'm curious how the approaches for the official SDK differ from MCP Daemon's. I've asked them as well https://github.com/entrepeneur4lyf/mcp-daemon/issues/4

[4t145]

I will have a look on this. And if there is anything we are not good enough or haven't done, please let us know.

[jokemanfire]

We can refer to the implementation of WebSocket @4t145

[Hendler]

@jokemanfire thank you for taking a look.
They use Actix, but this repo is using Axum. Axum websocket support seems good but I haven't used it https://docs.rs/axum/latest/axum/extract/ws/struct.WebSocket.html

Maybe the implementation won't be that different.
is there a TODO list or roadmap I can look to to know where to help?

[jokemanfire]

We can include websocket support in the to-do list, and you can develop it in parallel (and track the issue). We should add pre release transaction items in the future @4t145 @Hendler

[4t145]

@Hendler @jokemanfire We already have a websocket example. Websocket transport is not a part of MCP specification. If websocket transport become a de facto standard, we should support it but I haven't seen it so far.

[Hendler]

@4t145 got it. What is high priority on the todo list?

[jokemanfire]

It should be the first official release. Like #55 , Of course, CI documents and missing test cases are also included.

[jokemanfire]

@4t145 Can we include the issues or PRs to be done for the release of the first version in the milestone?

[4t145]

@jokemanfire @Hendler Let's create a 0.2.0 milestone.

[EItanya]

This repo definitely looks interesting, but also worth noting that this library uses traits to define all of the MCP operations, whereas this other one uses string paths. Not saying which is better, but the approach of this library does feel more ergonomic. This also brings up one more thing I wanted to mention about this library. I think it's worth logically separating the library into 2 distinct parts. The core, and the extensions. In my mind the core is everything that has to do with message handling, and the spec itself, and then extensions would be the implementation. When I say the implementation I mean the I/O aspects.. Why is this important? I for example am consuming this library only to use the core logic of the spec, and I will not be able to pull in any web libraries, or anything related to TLS. This will allow for users who want a quick way to start with MCP, and users who have use-cases specifically related to the core logic of the spec, and intend to build their own applications around it.

[Hendler]

This repo definitely looks interesting, but also worth noting that this library uses traits to define all of the MCP operations, whereas this other one uses string paths. Not saying which is better, but the approach of this library does feel more ergonomic. This also brings up one more thing I wanted to mention about this library. I think it's worth logically separating the library into 2 distinct parts. The core, and the extensions. In my mind the core is everything that has to do with message handling, and the spec itself, and then extensions would be the implementation. When I say the implementation I mean the I/O aspects.. Why is this important? I for example am consuming this library only to use the core logic of the spec, and I will not be able to pull in any web libraries, or anything related to TLS. This will allow for users who want a quick way to start with MCP, and users who have use-cases specifically related to the core logic of the spec, and intend to build their own applications around it.

@EItanya Looking at the official Typescript and Python implementations, it feels like this repo must be batteries included, but I agree it would be nice (or maybe critical) to have "core logic" be usable by repos like MCP daemon and your work.

[4t145]

@Hendler If you disable all the features you can also get a core crate here (I guess)

[ramnivas]

As @4t145 mentioned, disabling all features does give access to the “core” crate, but the cognitive load would be lower if there were a clearer separation between the true core (no web framework) and one connector for each web framework. This way, each connector can be developed independently, and using just the core becomes simpler. It also will make contributing another web framework easier (the current approach will need to add even more features).

From a developer experience standpoint, users could opt into rmcp-axum, rmcp-actix, etc., if they prefer a batteries-included setup.

I have a hand-rolled implementation that I’d like to migrate to this crate. My project already uses actix-web, so I only need the core functionality. It’s not a deal breaker if the current structure stays, but I did find it a bit harder to follow due to the mix of multiple concerns.

[Hendler]

As @4t145 mentioned, disabling all features does give access to the “core” crate, but the cognitive load would be lower if there were a clearer separation between the true core (no web framework) and one connector for each web framework. This way, each connector can be developed independently, and using just the core becomes simpler. It also will make contributing another web framework easier (the current approach will need to add even more features).

From a developer experience standpoint, users could opt into rmcp-axum, rmcp-actix, etc., if they prefer a batteries-included setup.

I have a hand-rolled implementation that I’d like to migrate to this crate. My project already uses actix-web, so I only need the core functionality. It’s not a deal breaker if the current structure stays, but I did find it a bit harder to follow due to the mix of multiple concerns.

Thank you @4t145 and @ramnivas
That's a great point of feedback. I will take a stab at a refactor that achieves this, but hopefully small enough so it's easy to give early feedback.