Skip to main content
← Back

MCP Server as a Wasm Component: OpenAPI to MCP, JCO & Component Model

The October 8, 2025 wasmCloud community call shows off an MCP server as a Wasm component. Bailey Hayes builds a Model Context Protocol server from idiomatic TypeScript, generates its tools from an OpenAPI spec with a new wash plugin, and compiles the whole thing to a portable, sandboxed WebAssembly component via JCO and StarlingMonkey. Victor Adossi traces the road to running plain JavaScript and WASI Preview 3 components in Wasm, and Brooks Townsend lands the wasmCloud runtime crate into wash ahead of Q4 roadmap planning.

Key Takeaways​

  • An MCP server can be a portable Wasm component. The Model Context Protocol's new streamable-HTTP transport compiles cleanly to a WASI HTTP component, so an MCP server built in TypeScript runs anywhere a Wasm component runs — no Node.js, no container.
  • OpenAPI to MCP turns an API spec into MCP tools. A new open-source wash plugin (itself a Wasm component) ingests an OpenAPI document and generates MCP tool definitions, scaffolding a working MCP server in seconds from a Pet Store or any enterprise API.
  • The developer writes idiomatic TypeScript, not Wasm. Using the official Model Context Protocol SDK plus Hono, wash dev runs npm install, compiles TypeScript to JavaScript, and componentizes it with JCO — the author never has to know WebAssembly is involved.
  • Sandboxing mitigates agentic risk. Wrapping an MCP server in a Wasm sandbox bounds the blast radius of agentic-software risks like prompt injection, data exfiltration, and improper input/output handling, letting teams adopt agentic tooling fast while keeping it contained.
  • StarlingMonkey is the JavaScript runtime inside the component. JCO's componentize embeds StarlingMonkey (a Bytecode Alliance runtime descended from SpiderMonkey and Fastly's Starling); WinterTC API support is what lets frameworks like Hono work today, with broader Node.js compatibility on the roadmap.
  • JCO is a second WASI P3 reference implementation. Alongside Wasmtime on the Rust side, JCO's jco transpile runs modern WebAssembly components in Node and the browser; with WASI Preview 3 release candidates landing, both ecosystems are racing to keep components running everywhere.
  • OCI layer de-duplication will shrink components. Today each component bundles a full copy of the StarlingMonkey runtime; the plan is to explode components into OCI layers so common runtimes de-dupe and you only download the bytes of your own code.
  • The wasmCloud runtime crate landed in wash. Brooks integrated the runtime crate (driving in-process component-to-component calls, built-in providers, and plugins) into wash, completing major Q3 roadmap work ahead of Q4 and KubeCon planning.

Chapters​

Meeting Notes​

Building an MCP Server as a Wasm Component​

Bailey Hayes demoed an MCP server template built with Victor Adossi and Mindy that turns the Model Context Protocol into a portable WebAssembly component. The Model Context Protocol lets MCP clients — VS Code, Claude, ChatGPT, and similar — connect to an MCP server to gain capabilities they otherwise lack, in this case making HTTP requests to an API and teaching the LLM the right way to call it. Because the spec's newest transport is streamable HTTP (plain HTTP rather than SSE), the server compiles straight to a WASI HTTP component that "can run anywhere." Cloning the template and running a single command, wash dev, handles npm install, the build, and spins up the Model Context Protocol Inspector for a tight dev loop.

OpenAPI to MCP: a wash Plugin That Writes the Tools​

The second half of the demo introduced OpenAPI to MCP, an open-source wash plugin (itself a WebAssembly component, published to OCI) that takes an OpenAPI spec document and generates MCP tools from it. Bailey scaffolded a Pet Store MCP server, then generated tools — getPetById, findPetsByStatus, addPet, and more — and exercised them through Goose, an LLM client she prefers for development because of its clear errors and lack of signed-cert requirements. Liam Randall then generated a second MCP server against the US Federal Reserve (FRED) economic-data API, using it to pull housing starts, the federal funds rate, and consumer confidence and chart them with a middle-school-friendly narrative — a live example of how quickly agentic tooling can be stood up and, crucially, sandboxed to mitigate risks like prompt injection and data exfiltration.

Inside the Build: Idiomatic TypeScript to a Sandboxed Component​

wash inspect on the output showed a lean WASI HTTP component with only the imports it needs to make outbound requests and handle incoming ones — far smaller than a Node.js process or a container while remaining sandboxed. The source is "regular old TypeScript" built directly on the official Model Context Protocol SDK plus Hono; there's no hand-written glue and the developer "has no idea you're doing WebAssembly stuff." Under the hood, JCO compiles the TypeScript to JavaScript and componentizes it into a .wasm, embedding the StarlingMonkey JavaScript runtime — a Bytecode Alliance project descended from Firefox's SpiderMonkey and Fastly's Starling edge runtime.

Runtime Crate Lands in wash, Plus Q4 Roadmap Planning​

Brooks Townsend announced that the wasmCloud runtime crate — which drives in-process component-to-component calls, built-in providers, and plugins beneath wash dev — is now fully integrated into wash in a large PR, completing significant Q3 roadmap work. He thanked recent wash contributors (Jacob, Luca, Junji) for steady fixes, clarified that the capability-provider model isn't going away in v2 (only the custom provider-archive packaging is, via the wRPC server effort) — a continuation of the Wasm-powered plugin system that the OpenAPI-to-MCP demo builds on, and set Q4 roadmap planning for two weeks out (October 22) to leave buffer for KubeCon prep in early November.

WebAssembly News and Updates​

This call captures the WebAssembly ecosystem meeting the agentic-AI moment head-on. The Model Context Protocol's move to a streamable-HTTP transport is what makes an MCP server compile to a stock WASI HTTP component, and tooling like the OpenAPI to MCP wash plugin shows how fast the gap between "API spec" and "running, sandboxed MCP server" is closing. On the language side, JCO and StarlingMonkey continue to push toward running unmodified JavaScript in Wasm via WinterTC and growing Node.js compatibility, while WASI Preview 3 release candidates are landing and JCO is standing up as a second reference implementation alongside Wasmtime. For ongoing updates, follow the Bytecode Alliance and the WASI subgroup.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and increasingly Java) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and as this call shows, the same component model lets you take idiomatic TypeScript — even an off-the-shelf MCP server SDK — and ship it as a portable, sandboxed Wasm component. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Every thread in this meeting traces back to the Wasm component model. It is what lets a TypeScript MCP server, a Rust-compiled HTTP client, and a host runtime interoperate through typed interfaces (WIT) without any side trusting the other's internals — exactly the "bag of composable capabilities" symmetry Ian and Corey noticed maps so naturally onto MCP servers. It's why the OpenAPI-to-MCP plugin can be a Wasm component too, installed into wash and run as portable, sandboxed code. And it's the reason JCO matters as a second reference implementation: a component is a component whether you run it in Wasmtime on the Rust side or via jco transpile in Node, so the work to keep modern components — soon including WASI Preview 3's async, streams, and futures — running consistently across runtimes is foundational. As OCI-layer de-duplication arrives, that same component model is what makes sharing a single StarlingMonkey runtime across many scripts possible without breaking portability. wasmCloud's bet is that the component model becomes the universal contract across languages, hosts, and the MCP-and-agent tooling now converging on it.

Who Should Watch This​

This call is especially valuable for AI and platform engineers standing up MCP servers who want them portable and sandboxed rather than tied to a single cloud (start with the demo intro at 6:39), JavaScript/TypeScript developers tracking how idiomatic code becomes a Wasm component via JCO and StarlingMonkey (the build deep dive at 23:32 and the roadmap discussion at 33:13), and Wasm tooling builders exploring different architectural approaches to MCP and the component model (Ian and Corey at 46:43).

Up Next​

The next community call will feature a demo from Ian and Corey on their WIT-native approach to real-time agent tools and MCP servers, exploring how their tooling and Cosmonic's OpenAPI-to-MCP approach might converge. Beyond that, watch for Q4 roadmap planning on October 22, the wasmCloud runtime crate moving into the released binary, and a KubeCon mini-epic in early November.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →