Skip to main content
← Back

openapi2mcp Wasm Plugin Demo, WASI P3 & JCO Async for the Component Model

Watch on YouTube ↗

The October 29, 2025 wasmCloud community call is a short, demo-led session focused on the Wasm component model and the tooling around it. Liam Randall demos the new openapi2mcp plugin for Wasm Shell, which turns an OpenAPI specification into a ready-to-run MCP server packaged as a WebAssembly component, then shows pushing it to Kubernetes and wiring it into Claude. Victor Adossi gives a WASI P3 update: the P3 feature set is essentially complete on the Rust side, and his JCO async work — transpiling P3 components to JavaScript for Node and the browser — is on track to become the second WASI P3 reference implementation.

Key Takeaways​

  • The openapi2mcp plugin for Wasm Shell generates a full set of MCP tools from any OpenAPI spec, scaffolding a TypeScript MCP server in a Wasm sandbox so you can stand up an integration without hand-writing tool definitions
  • wash dev drives the whole loop — it detects the TypeScript project, runs the idiomatic build, and (via pre/post plugins) launches an MCP inspector so you can speak the MCP protocol and exercise the generated tools immediately
  • The generated server is a portable WebAssembly component that can be pushed to Kubernetes, run in a container, or connected straight into Claude as a tool source — the demo used the FRED economic-data API from the Federal Reserve as a real-world OpenAPI source
  • Agentic workflows introduce agentic-specific risks, and packaging MCP servers as deny-by-default Wasm components is the security story behind the sandbox MCP effort
  • The CNCF is moving to a new community calendar at cncf.io/calendar; the wasmCloud meeting is listed there and will transition to a new Zoom ID over the coming weeks
  • WASI P3 is essentially feature-complete on the Rust side, including the new built-ins for async, streams, and futures, making it straightforward to build a P3 component in Rust today
  • JCO transpile turns a P3 component into JavaScript — a Wasm module plus glue code that runs in Node (browser support is experimental) — putting JCO on track as the second WASI P3 reference implementation the WASI subgroup needs to advance the spec
  • Call for papers are open for WasmCon at KubeCon EU 2026 (deadline November 2) and a separate submission deadline of December 24 — wasmCloud users are encouraged to submit to both

Chapters​

Meeting Notes​

Announcements: Community Summit, Munich, and a New CNCF Calendar​

Bailey Hayes opened the last Wednesday of October with a quick travel recap. The previous week she attended the WebAssembly Community Summit, where demos included compiling Java to WebAssembly and debugging JavaScript, Python, and Rust simultaneously inside WebAssembly. This week she joined the WebAssembly Community Group meeting in person in Munich, so the call was kept short.

Liam Randall noted a logistics change: the CNCF is moving to a new process for scheduling community calendars. Subscribers can find the wasmCloud meeting on the new community calendar at cncf.io/calendar, and over the coming weeks the meeting will transition to a new Zoom ID. The current subscription still carries the existing link in its notes during the changeover.

Demo: The openapi2mcp Plugin for Wasm Shell​

Continuing the tradition of starting wasmCloud Wednesdays with a demo, Liam walked through the newly released openapi2mcp plugin for Wasm Shell (wash). He started with wash new to pull down a template — a small Hono package with the prerequisites for building an MCP (Model Context Protocol) server — then dropped in an OpenAPI specification for the FRED database, the Federal Reserve's repository of decades of economic data (the demo API key shown in the notes is a placeholder, not a real credential).

The plugin reads the OpenAPI spec and automatically generates a TypeScript tool for every API definition, removing the need to hand-write MCP tool definitions. OpenAPI sits between your APIs and databases and an LLM-driven client like a code assistant, so generating the tools straight from the spec is a fast path from an existing API to a working MCP server.

Demo: Testing the Tools and Deploying to Kubernetes​

With the tools generated, Liam ran wash dev, which spun up a development server in the background. Because wash recognizes the TypeScript project, it ran the idiomatic npm run dev build loop, and — since wash plugins now support pre- and post-plugins — it launched an MCP inspector as a post step. That let him speak the MCP protocol directly, browse the generated tools, and send in parameters to test the interface live.

For the "bake the cake" finish, Liam noted the generated artifact is a portable WebAssembly component: it can be pushed to Kubernetes, run in a container, or — his preferred path, running wasmCloud via Cosmonic Control — connected straight into Claude as a tool source by pasting in a URL and asking it to create graphs or pull reports. He framed the broader motivation around the agentic-specific risks that MCP and agentic workflows introduce, the subject of ongoing white papers and blog posts; the plugin is open source and documented at sandboxmcp.ai.

Community Updates: Call for Papers and Roadmap​

Bailey flagged two call-for-papers deadlines worth noting: the WasmCon submission for KubeCon EU 2026 (deadline November 2) and a separate submission deadline of December 24 for Wasm.io 2026 — plenty of runway for procrastinators, and a reason to submit to both. She also noted that the full roadmap planning she wanted to do would land the following week, with links to follow in the wasmCloud Slack.

WASI P3, JCO Async, and a Second Reference Implementation​

Victor Adossi gave the technical update. On the Rust side, the WASI P3 feature set is essentially finished, including the new built-ins for async, streams, and futures, so building a P3 component in Rust is now straightforward (he pointed to community example repos, including a P3 HTTP component). The harder, more interesting question is what happens next: taking that P3 component and running jco transpile on it.

JCO transpile converts a WebAssembly component into a JavaScript file — a Wasm module plus glue code — so it can run in a JavaScript environment, either Node or the browser. Victor's focus is ensuring that everything a working Rust P3 component does also works on the JavaScript side, including the lower-level built-ins and the shims for interfaces like WASI standard out, which changed in P3. Node support should work; browser support is experimental. He thanked community contributors who have been kicking the tires and filing bugs, and encouraged anyone building P3 components to try transpiling them and report issues on the JCO repo.

Bailey explained why this matters: to advance the WASI P3 subgroup work, the spec needs two reference implementations. Wasmtime is one; Victor is leading the second by taking the specs and making them run in a Node.js environment via JCO transpile. Reports, examples, and usage feedback are critical to hitting the target date.

WebAssembly News and Updates​

This call is a compact snapshot of two converging WebAssembly trends. On the tooling side, the openapi2mcp plugin for Wasm Shell shows the component model meeting the agentic moment — turning an OpenAPI spec into a deny-by-default MCP server packaged as a portable Wasm component (more at sandboxmcp.ai). On the standards side, WASI P3 is nearing the milestone of a second reference implementation: with the feature set complete in Wasmtime on the Rust side, JCO is standing up the JavaScript path via jco transpile for Node and the browser. Bailey also relayed news from the WebAssembly Community Group meeting in Munich and the WebAssembly Community Summit, where compiling Java to WebAssembly and multi-language Wasm debugging were on display. 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 tooling like Wasm Shell (wash) makes it easy to scaffold, test, and ship those components — including, as this call shows, an MCP server generated from an OpenAPI spec. 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​

Both halves of this meeting trace back to the Wasm component model. The openapi2mcp demo only works because the generated MCP server is a component: a typed, sandboxed unit that wash dev can build, an MCP inspector can probe over a standard interface, and the same artifact can be pushed to Kubernetes or handed to Claude without changing its shape. That is the component model's promise — write the logic once, run it in any host that speaks the model.

Victor's WASI P3 work is the same story at the specification layer. P3 extends the component model with native async, streams, and futures, and the way you prove the spec is real is by having two independent implementations agree on its behavior. Wasmtime implements it for Rust; JCO transpiles P3 components into JavaScript so they run in Node and the browser. A second reference implementation that produces equivalent behavior across platforms is exactly what the WASI subgroup needs to move P3 forward — and it is what makes "a component built in Rust runs unchanged in a JavaScript runtime" a concrete reality rather than an aspiration. As more of the ecosystem implements the component model, the universal-contract bet at the center of wasmCloud gets stronger.

Who Should Watch This​

This call is especially useful for developers building MCP servers and agentic integrations who want to skip hand-writing tool definitions — start with Liam's openapi2mcp demo from 4:50; JavaScript/TypeScript developers tracking how to run WASI P3 components in Node and the browser via JCO transpile (Victor's update at 12:09); and platform engineers interested in packaging tools as portable Wasm components and pushing them to Kubernetes (the deployment walkthrough at 7:00).

Up Next​

The next community calls will carry the WASI P3 thread forward as JCO matures into a full second reference implementation, alongside the roadmap planning Bailey promised to post in Slack. Watch for more on packaging MCP servers as Wasm components, continued community testing of jco transpile for P3, and the eventual transition to the new CNCF community calendar and Zoom ID. Submissions for WasmCon at KubeCon EU 2026 are due November 2.

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 →