Cloudflare Worker support

[sagikazarmark]

Has anyone tried running a server on Cloudflare Workers yet?

I'm trying to build an MCP server that runs on CF, but so far all frameworks I found have tokio and other components hard-wired into them that don't work on CF or don't even compile to WASM.

I briefly looked at the architecture and I have a good feeling given how nicely everything is modularized, but I thought I'd ask first or start a conversation.

Thanks!

[nicholasjpaterno]

@sagikazarmark that's a great question! I'll have to give this a test myself.

What I can say is I've been working on v3 for the past 2 months or so that will absolutely work on CF Workers! If you're interested, I can ship an -exp release if you would like to give it a test run for your use case?

[sagikazarmark]

@nicholasjpaterno I'm definitely interested!

[nicholasjpaterno]

@sagikazarmark I'm hoping to ship this within the next few hours!

[nicholasjpaterno]

@sagikazarmark Let me know how this works for you! https://github.com/Epistates/turbomcp/releases/tag/v3.0.0-exp

[sagikazarmark]

Hm, it seems to me a lot of packages still pull in tokio with net, signal, and process features. Those won't work on wasm32-unknown-unknown.

Any chance that's still WIP?

I'm trying these dependencies:

[dependencies]
worker = "0.7.2"
turbomcp = { version = "3.0.0-exp", default-features = false }
getrandom = { version = "0.3", features = ["wasm_js"] }

Th culprits are:

1. turbomcp-transport-traits - requires tokio features: net, signal, process, rt-multi-thread
2. turbomcp-transport - requires the same heavy tokio features
3. turbomcp-server - same
4. turbomcp-protocol - requires tokio with net, signal, process
5. turbomcp itself - requires all of these

[sagikazarmark]

Slight correction: some of these features come from the workspace.

I think the only way to make this work is selectively enabling the features of tokio where needed.

Generally the following features work on wasm32:

• sync
• macros
• io-util
• rt

I don't see how process or signal would compile for wasip.

Maybe I'm doing something wrong though.

[sagikazarmark]

Okay, I figured out there is a turbomcp-wasm crate, but it only implements clients for now. What I wanted to do is implement a server and run it on Cloudflare.

[nicholasjpaterno]

@sagikazarmark I had some smoke tests running overnight and everything is looking good I just need to make one change and I’ll be shipping the wasm server today with v3.0.0-exp.1

[nicholasjpaterno]

Hey @sagikazarmark! Great news - we've just shipped native Cloudflare Workers support in v3.0.0-exp.1

Quick Start

[dependencies]
turbomcp-wasm = { version = "3.0.0-exp.1", default-features = false, features = ["wasm-server"] }
worker = "0.7"
serde = { version = "1.0", features = ["derive"] }
schemars = "1.0"
getrandom = { version = "0.3", features = ["wasm_js"] }

use turbomcp_wasm::wasm_server::{McpServer, ToolResult};
use worker::*;
use serde::Deserialize;

#[derive(Deserialize, schemars::JsonSchema)]
struct HelloArgs {
    name: String,
}

#[event(fetch)]
async fn fetch(req: Request, _env: Env, _ctx: Context) -> Result<Response> {
    let server = McpServer::builder("my-mcp-server", "1.0.0")
        .with_tool("hello", "Say hello", |args: HelloArgs| async move {
            Ok(ToolResult::text(format!("Hello, {}!", args.name)))
        })
        .build();

    server.handle(req).await
}

Key Features

• Zero Tokio - Uses wasm-bindgen-futures for async, no tokio runtime
• Type-Safe Tools - Automatic JSON schema generation from Rust types via schemars
• Full MCP Protocol - Tools, resources, prompts, JSON-RPC 2.0 compliant
• CORS Built-in - Preflight handling for edge deployment
• ~536KB binary - Reasonable size for Workers

Documentation

• WASM Guide - Building MCP Servers section
• WASM API Reference - Server API section
• Edge Deployment - Native MCP Server (Rust) section
• Crate README

Let us know how it works for you! Would love feedback on the API ergonomics.

[nicholasjpaterno]

The npm package still needs to be shipped.

[nicholasjpaterno]

Just published. Appreciate any and all feedback, I'll be thoroughly testing today as well: https://www.npmjs.com/package/turbomcp-wasm

[sagikazarmark]

A.W.E.S.O.M.E.

I'll give it a try shortly.

~536KB binary - Reasonable size for Workers

I think it's very reasonable. I don't think I have workers smaller than that.

[nicholasjpaterno]

Amazing! Thanks for the support and feedback @sagikazarmark.

Just a gentle reminder - please consider it experimental for now. Take extreme caution shipping it to production environment until it's been thoroughly tested. Please let me know any and all issues that you might see.

[sagikazarmark]

@nicholasjpaterno I managed to get it working!

Couple random thoughts about the API:

• Would be nice to configure tools through macros or trait implementations or something to make the code more readable
• The result is a bit weird. Haven't figured it out fully, but it makes error handling less idiomatic (ie. no ?)
• Using a trait like IntoToolResponse would allow converting types to a response automatically?

[nicholasjpaterno]

@sagikazarmark thanks for the quick feedback! I ran into some of these as well and I'm working on a fast follow. The main issue is the existing turbomcp-macros, they generate code that depends on:

• turbomcp::RequestContext, turbomcp::ContextFactory
• turbomcp::__macro_support::turbomcp_server::McpError
• Native server infrastructure (tracing, metrics, etc.)

These won't work in WASM because they assume the native tokio-based runtime.

I'm rewriting the macros now to be runtime agnostic, its actually not a huge change!