Is your feature request related to a problem? Please describe.
I want to use this crate in a sandboxed WASM environment, but its dependency on tokio complicates effectiev usage.
Describe the solution you'd like
Tokio support would be moved into a seperate crate or feature for rmcp; the core functionality would become no_std as it does not perform IO itself.
Describe alternatives you've considered
- Other MCP libraries, although this one is official and fully matches how an MCP server is expected to act
- Using my binary rewriting libraries in Rust would also work, though they would need significant effort (which, even with AI, will still be too much effort) to be able to recompile
rmcp's native binaries to WASM
- WASI might work for the
stdio transport, but I would be unable to use networking, limiting the kinds of MCP servers I could create
Additional context
I do NOT want a hard dependency on wasm_bindgen on WASM, as it supports only the web, while I want all WASM environments supported
Is your feature request related to a problem? Please describe.
I want to use this crate in a sandboxed WASM environment, but its dependency on
tokiocomplicates effectiev usage.Describe the solution you'd like
Tokio support would be moved into a seperate crate or feature for
rmcp; the core functionality would becomeno_stdas it does not perform IO itself.Describe alternatives you've considered
rmcp's native binaries to WASMstdiotransport, but I would be unable to use networking, limiting the kinds of MCP servers I could createAdditional context
I do NOT want a hard dependency on
wasm_bindgenon WASM, as it supports only the web, while I want all WASM environments supported