Transcript: openapi2mcp Wasm Plugin Demo, WASI P3 & JCO Async for the Component Model
wasmCloud Weekly Community Call — Wed, Oct 29, 2025 · 16 minutes
Speakers: Bailey Hayes, Liam Randall, Victor Adossi
Transcript
Bailey Hayes 03:02
All right, looks like we're underway. Hello, folks. This is the last Wednesday of October. It's about to get really spooky, so I hope everybody has a really wonderful Halloween this week. We've got a short one today — at least for me, I've been traveling. Last week was the WebAssembly Community Summit, where they showed off some pretty cool demos: compiling Java to WebAssembly, and also debugging JavaScript, Python, and Rust all at the same time in WebAssembly, which was pretty cool. I'll try to get some links out and share those on the wasmCloud Slack, because that just totally blew me away.
And then this week was the WebAssembly Community Group meeting in person in Munich, so I am in a hotel room — and that's why. So we're going to keep this one fairly short, but I believe Liam has brought a demo today, so we'll start there.
Liam Randall 04:02
Yeah, great. First, maybe a quick announcement. I'll just share my screen — the CNCF is moving to a new process for scheduling your calendars. So if you have not yet subscribed, if you go to cncf.io/calendar, there is now a new community calendar that should have the wasmCloud meeting listed on it. Now, in the next few weeks — maybe months, I'm not sure of the timeline — we will be transitioning to a new Zoom ID. There's the wasmCloud community meeting, and if you actually subscribe to this, in the notes it has our old link in here as well. So we will be moving to that.
But in the meantime, I wanted to go ahead and kick off a demo of the new sandbox MCP plugin that we have just released, and we always love to start wasmCloud Wednesdays with a demo. Let me just find my notes here. So what I'm going to start with — we've released a few templates here for the sandbox MCP plugin that folks can start to leverage. I'm going to start with wash new and pull down a template repository. What this is, is a simple Hono package that has the prerequisites you can use to build an MCP server.
Now, for this particular demo, what I'm going to do today is pull down an OpenAPI spec for the FRED database. The FRED database, if you don't know what that is, is a database from the Federal Reserve, and it has decades of economic data — it's this fabulous resource. So I've cloned my repo here, and then I've pulled down this OpenAPI spec, which has a number of API definitions. Now, I think there is an API key here that's listed — this is a fake API key, it's not real. It just shows up in the notes in the description.
And then once I've done that, I can use this new plugin for wash. We've been talking about wash plugins for a while, and what this one does is take an OpenAPI specification and automatically generate all of the tools that you would use for OpenAPI. Now, OpenAPI is a standard that sits between your APIs, your databases, and an LLM — or a tool like a code assistant — can use it. So it's asking me permission if it can pull down some additional templates and resources. And then it's gone ahead and generated a set of tools here in this template. You can see now, for every API definition, I have a TypeScript tool.
Now I can simply just launch wash dev, and what wash is going to do for us, of course, is spin up a development server in the background. It's going to give me the idiomatic experience for TypeScript — so in the background it's going to say, "Hey, this is TypeScript in this repo, let's try to do the right thing" and do an npm run dev build loop here. And then it's going to ask — because wash plugins now support pre- and post-plugins — if it can launch a little server here in order to help us out. This particular server is an MCP inspector that we can now use in order to test out this particular interface. So if you're following along, what this looks like is: now I'm speaking the MCP protocol. I can come in and look at the tools that are here, and I could start interacting with it and sending in parameters.
Now, to give you the bake-the-cake experience: I could push this to Kubernetes, I could run this in a container, or — my favorite way to run wasmCloud is using Cosmonic Control — I could connect this right into Claude as a component. So here it's pretty simple: I just put in the URL, and then I could start asking it questions, asking it to create graphs, pull reports, or whatever the case would be.
So if you haven't had a chance to play with this plugin yet, it's open source and available at sandboxmcp.ai, and we'll walk you through the instructions and a quick demo, and we explain a lot of why this is important. I think when you're considering MCP or agentic workflows, what's painful about them is that they really introduce new agentic-specific risks — and that's some of the stuff we're talking about in these various white papers and blog posts. Any questions, just open it up here. I just wanted to start with a quick demo, let folks see some of the tooling that we've been building out and some of the stuff we're trying to put out in the ecosystem. All right, Bailey, I'll go ahead and hand it back to you.
Bailey Hayes 09:48
Yeah, thank you. I realized that there are some call-for-paper deadlines that are worth giving a shout-out. The WasmCon submission for KubeCon EU is a November 2 deadline; the other deadline is December 24, so you have tons of time — so procrastinators like me are like, "I'll wait on that one." But hey, if you're doing wasmCloud, why not do both at the same time and get a check mark for the day? So I dropped some links to that in the chat.
In terms of community updates, we're continuing on WASI P3. Victor is doing an awesome job pushing out JCO async support. I understand he's got some more examples working now as of this week — go Victor. If you want to say anything about that, Victor — I don't know if you're in a place where you can open your mic, but I think it's worth giving a shout. And then otherwise, I was just going to say I didn't have a chance to put together all of the roadmap planning that we wanted to do this week, so I will get that done for next week, and I'll post a bunch of links about that inside the wasmCloud Slack. Hey, Victor.
Victor Adossi 10:56
Hey, hey Bailey. Yeah, hope you're enjoying the travel. With regards to the async work that's going on in JCO: thanks to a bunch of people from the community who are kicking the tires on it — Christoph, and there have been a few other contributors, I know Sander, and Ruslan. I can't remember exactly — sorry, I've almost certainly butchered your name there. But the contributions, and people filing bugs as they find them, has been great.
The async support in JCO is not fully ready yet, but you can try it, and if you run into issues — like you almost certainly will — please, please file issues. There are some flows that work right now, but obviously not all the flows work. So basically what I'm doing is going through as many test cases as I can find, and making sure that we can confirm P3 functionality.
Victor Adossi 12:09
On the Rust side — for people who aren't familiar, just to step back and explain things — the new features and all of P3 are essentially finished on the Rust side now. That includes the new built-ins that got added for P3 async stuff, and streams and futures and things like that. So it's straightforward to build a P3 component right now in Rust. There are actually great repos out there that are examples — you can build, for example, a P3 HTTP component. Thanks to Joel for his; he's got a repo out there which I'll link in the chat later.
So you can build a P3 component now in Rust. Can you take that P3 component and take it to JCO and do a transpile? For those who aren't familiar, JCO transpile converts a component into essentially a JavaScript file — a WebAssembly module and glue code that makes it so you can run it in a JavaScript environment. So that means either Node or the browser. We're taking the P3 component we built in Rust — that's feature-complete right now; there may be some bugs we'll find, but it's pretty stable-looking at this point — and we're transpiling that component to something that can run in JavaScript.
So the problem I'm working through now is making sure that all the things the working Rust P3 component tries to do will work on the JavaScript side. And browser support is experimental, but Node support should certainly work. So just making sure that all the lower-level new built-ins — and then also the shims, because things like WASI have also changed in P3. If you think of WASI standard out and all this other stuff, that stuff's changed too. So just trying to make sure those things work in an equivalent way, as much as they can be equivalent across these platforms, is what I'm doing now. So that work's underway. If you're building P3 components out there, try transpiling them, see if you run into any bugs, and if you do — which you probably will — just send them my way. And this is, again, on the JCO repo.
Bailey Hayes 15:03
Yeah, and the reason why that's so important is, for us to basically move to phase three for WASI P3 as part of the WASI subgroup, we have to have two reference implementations. And so Victor is leading out the second reference implementation, which is taking these specs and making them run in a Node.js environment with JCO transpile. Getting help on reports, examples, and usage is really critical for us to be able to make our date. And thank you, Victor, for taking that on. Any questions on that front?
All right, well, we're going to get back to it and stay heads-down. So thank you, everybody, for joining, and I'll see you next week.
Liam Randall 15:58
All right, have a great week, everybody. Bye.