WASM Support for rmcp

[joulei]

Hi! I'm working on integrating rmcp into a project that requires WASM compatibility and noticed that rmcp currently doesn't compile for wasm32-unknown-unknown due to several WASM-specific blockers, mostly Send requirements.

Current Issues:

1. Send trait bounds incompatibility

   • traits likeSseClient requiree Send + Sync + 'static
   • Send is a no go in web:
     • JavaScript interop types contain PhantomData<*const u8> making them intentionally !Send
     • reqwest's WASM implementation uses JsValue types that are !Send by design

2. Transport trait architecture

   • All transport implementations must return impl Future + Send

3. Worker transport assumptions

   • Worker trait expects thread spawning capabilities
   • WASM is single-threaded, no std::thread support

4. Service layer threading

   • ServiceRole, Service traits all require Send + Sync
   • Future return types across the codebase assume Send bounds

Questions:

1. Is WASM support planned for rmcp in the near future?
2. Is anyone currently working on this?

Proposal:

I'm willing to work on this if there's interest (I might do either way in a fork, as I'd really like to avoid making my own rmcp). We've recently had to deal with similar issues making some cross-platform async Rust projects wasm-compatible, there are some patterns we've used that could work here:

1. Platform-conditional trait abstractions:

  cfg_if::cfg_if! {
      if #[cfg(target_arch = "wasm32")] {
          pub trait PlatformSend {}
          impl<T> PlatformSend for T {}
      } else {
          pub trait PlatformSend: Send {}
          impl<T> PlatformSend for T where T: Send {}
      }
  }

  pub trait SseClient: Clone + PlatformSend + 'static { ... }
  pub type BoxPlatformSendFuture<T> = Pin<Box<dyn Future<Output = T> + PlatformSend>>;

2. ThreadToken pattern for WASM:

• If needed, use thread-local storage for non-Send types that need to cross Send boundaries
• ^ safe access to JavaScript objects in single-threaded WASM context

3. Conditional spawn implementations:

  #[cfg(not(target_arch = "wasm32"))]
  fn spawn_worker(fut: impl Future + Send + 'static) { tokio::spawn(fut); }

  #[cfg(target_arch = "wasm32")]
  fn spawn_worker(fut: impl Future + 'static) { wasm_bindgen_futures::spawn_local(fut); }

I haven't dug in depth through rmcp (I've wrote this based on what I've seen from the client-side), but we've recently done similar things in other projects and have some experience in maintaining API compatibility while supporting both native threading and WASM.

Would love to hear your plans (if any) regarding WASM support, and if it's something you'd accept PRs on.

[4t145]

Good point. And we can consider this with #290.

I think it could be useful to support wasip2, but tokio still doesn't have a good compatibility with wasip2, and I was failed to find a widely accepted async runtime for wasip2.

As for calling rust mcp sdk from JavaScript, I think it could be better to use typescript sdk?

[joulei]

@4t145 I see, thanks for the reply. (sorry I closed the issue by mistyping a shortcut)

What do you think about having iterative improvements for WASM support?
For my WASM use case in particular, I don't need to call the SDK from JavaScript, or to create mcp servers, or use stdio.
(though you raised good points about wasip2 and typescript sdk, I'll take a look)

We have a Makepad application that runs on all platforms and allows users to interact with local and remote AI providers, for WASM we just want to be able to talk with remote or local MCP servers using HTTP/SSE (unless stdio is possible somehow).

We could start with making the traits not requiring Send, or at least not in WASM builds, and some other minor improvements like runtime-agnostic task spawning.
With that in place we (as in my project) could work around some of the other rmcp WASM limitations, from the application side, until the rest of rmcp fully supports WASM.
This could help us (and rmcp) move towards WASM support, without having one huge pile of work making the entire library runtime-agnostic and WASM-compatible.