Change MCP SDK to rmcp

[byeblack]

Reason: modelcontextprotocol/rust-sdk#44, the original MCP rust-sdk has been changed to rmcp, we should use rmcp to fix #416

[byeblack]

Sorry, I didn't notice that the maintainer of mcp-core used by rig is @stevohuncho, but I really want to use https://github.com/modelcontextprotocol/rust-sdk Maybe we need more discussion to make a choice.

[0xMochan]

When MCP support was first PRed, I don't think anthropic even had a rust-sdk out yet. This is just the nature of how fast this space moves. iirc, @stevohuncho's goal was to merge upstream into the official one (though it might be tricky). it seems like the official one decided to swap to rcmp directly (iirc, the crate name for mcp-core was offered but ig ignored?) and now the contributing efforts have settled there so it might be suitable.

although...., there's no reason why both can't be supported. it just's simpler for us to promote one (except for implementing a foreign trait on a foreign type but you can use a wrapper type for that).

[byeblack]

When MCP support was first PRed, I don't think anthropic even had a rust-sdk out yet. This is just the nature of how fast this space moves. iirc, @stevohuncho's goal was to merge upstream into the official one (though it might be tricky). it seems like the official one decided to swap to rcmp directly (iirc, the crate name for mcp-core was offered but ig ignored?) and now the contributing efforts have settled there so it might be suitable.

although...., there's no reason why both can't be supported. it just's simpler for us to promote one (except for implementing a foreign trait on a foreign type but you can use a wrapper type for that).

After careful evaluation, I confirmed that rmcp and mcp-core are fundamentally incompatible due to completely different API designs. Maintaining both implementations would significantly increase complexity and maintenance overhead.

We can:

1. Adopt rmcp as the primary MCP implementation
2. Temporarily retain mcp-core behind a feature flag:

   #[cfg(feature = "legacy-mcp")]

   while marking it as deprecated
3. Schedule complete removal in a future release

I'd appreciate @stevohuncho's input on this migration plan before we proceed.

[joshua-mo-143]

If rmcp has complete feature parity with mcp-core I'd be personally happy to move forward on this.

[byeblack]

If rmcp has complete feature parity with mcp-core I'd be personally happy to move forward on this.

Yes, they are nearly identical in terms of functionality.
Here are the key differences that need to be confirmed:

Feature	rmcp	mcp-core
API Implementation	Different architecture	Different architecture
STDIO Transport Support	✅ Yes	✅ Yes
SSE Transport Support	Using axum	Using actix-web
2024-11-05 Revision	✅ Full schema support	⚠️ Basic support only
2025-03-26 Revision	⚠️ schema and corresponded service logic	❌ Not yet started
Transport Extensibility	✅ Extensible design	✅ Extensible design

But they have their own problems, this is just a rough comparison...

[stevohuncho]

I think in the immediate term adding rmcp as a sep mcp feature and then fully removing mcp-core is fine by me. I was busy working on another project until recently, so I just started pushing updates again to the mcp-core repo. However, I want to contribute these efforts to rmcp anyways now that they have a crate.
I like building my mcp servers with mcp-core currently, but the good thing is the mcp feature within rig only has the purpose to be the mcp client. Thus, its interactable with my crate and any crates mcp servers.
However core devs want to handle this works with me 👍

[0xMochan]

I think in the immediate term adding rmcp as a sep mcp feature and then fully removing mcp-core is fine by me. I was busy working on another project until recently, so I just started pushing updates again to the mcp-core repo. However, I want to contribute these efforts to rmcp anyways now that they have a crate. I like building my mcp servers with mcp-core currently, but the good thing is the mcp feature within rig only has the purpose to be the mcp client. Thus, its interactable with my crate and any crates mcp servers. However core devs want to handle this works with me 👍

I think this makes sense, adding rcmp as a separate feature atm would work. I think we could also migrate the current rig x mcp-core integration onto the mcp-core side so that folks using mcp-core can continue to enjoy a rig integration while we fully move to rmcp. I think this makes the most sense to me, but we'll want to support both for a period of time as a transition.

[byeblack]

I think in the immediate term adding rmcp as a sep mcp feature and then fully removing mcp-core is fine by me. I was busy working on another project until recently, so I just started pushing updates again to the mcp-core repo. However, I want to contribute these efforts to rmcp anyways now that they have a crate. I like building my mcp servers with mcp-core currently, but the good thing is the mcp feature within rig only has the purpose to be the mcp client. Thus, its interactable with my crate and any crates mcp servers. However core devs want to handle this works with me 👍

Thanks for your supportive stance! I agree—adding rmcp incrementally while keeping mcp-core temporarily is the pragmatic path.

That said, rmcp’s development could use more momentum (e.g., 2025-03-26 Protocol Revision isn’t fully supported yet). If you’re open to contributing there, your expertise would be invaluable!