Microsoft’s fascination with AI agents as a tool for developers continues with Wassette, a new open source release from its Azure Core Uptime team. Built in Rust and designed to host pieces of functionality written as WebAssembly Components, it’s a first step to delivering customizable and composable functionality that can be deployed as a tool for a local agent—in this case, the GitHub Copilot agent running in Visual Studio Code or any other Model Context Protocol-aware agent.

Wassette is, at heart, relatively simple. It loads and runs components, sandboxing them using the familiar Wasmtime runtime, and provides an MCP interface by translating their interfaces to MCP functionality. Using Wassette and a mix of your own and public WebAssembly components, you can quickly assemble a library of secure tools tailored to a specific project.

Working with Wassette in VS Code

Getting started is simple enough. Although I had trouble running the Arm version of Wassette both in Windows and in Linux, the X64 version worked the first time. Windows users can install using WinGet. Linux users can use curl and an install script. Other options include Homebrew support or using Nix to set up a development shell with Wassette.

One minor issue did arise: A false positive virus detection in Windows Defender meant I had to temporarily disable my antivirus tools to complete the WinGet-based install. There is a related GitHub issue noting that the development team is working to register Wassette’s signature to avoid this in the future.

Once installed, you need to register the Wassette MCP server with your developer tool. Microsoft provides instructions for Visual Studio Code, Cursor, Claude Code, and Gemini CLI. I did find that the script the documentation suggested for VS Code failed, and I had to install MCP manually using the tool built into VS Code’s GitHub Copilot Agent UI. This required having to reinstall each time I restarted VS Code. Hopefully an updated version of the Wassette tool will fix this. It’s not a dealbreaker, but it is a bit awkward to repeatedly reload it.

When the Wassette MCP server runs inside the GitHub Copilot Agent, you can start to use it. It will appear as another tool alongside other registered servers. You should note that if you have more than 128 tools registered in GitHub Copilot it can be slow to select the right tool for your prompt.

The documentation provides a link to a basic time client that extends the base GitHub Copilot functionality. From the GitHub Copilot chat UI, I was able to load this from a remote OCI registry. The agent selected the Wassette MCP server and loaded the WebAssembly component. I could then use it to get the current time, a feature the base agent was unable to offer.

An extensible, secure MCP server

Getting the time may seem to be a relatively trivial feature to add to the GitHub Copilot agent, but it’s only an example of what you can do with Wassette. This is an extensible platform; if a feature isn’t available, you can quickly write your own and add it. The added bonus of running in a WebAssembly sandbox reduces risk by isolating modules from each other and from the OS and the IDE.

Much of the security model comes from Wasmtime, as it builds on a least-privilege model. A component loaded into Wassette must have explicit permissions for the services it needs, and it uses the agent chat interface to request them as needed. For example, a component that needs network access will request permission for each specific domain it connects to. This ensures that a module that gets the time from your PC’s lock won’t send your application keys to a nefarious domain. If it requests network permissions when you aren’t expecting them or for a domain you didn’t request, you can use the agent to block it.

Microsoft has provided a set of sample tools to show what can be done with Wassette. They’re all WebAssembly components, written in a selection of different languages. These include Python, JavaScript, Rust, and Go. If there’s Wasmtime support for a language, you can build a component with it, ready for use in Wassette.

Adding features with WebAssembly components

It’s important to understand that you don’t need to do anything with a WebAssembly component to use it with Wassette. I’ve previously described the Model Context Protocol as a modern equivalent of tools like CORBA’s Interface Definition Language, as it takes APIs and other interfaces and wraps them in an agent-ready description with a common way of sending and receiving information.

Wassette does this by taking advantage of one of the key features of WebAssembly components: the fact that they expose functions as strongly typed library interfaces. Wassette can use any existing (and future) components, giving you eventual access to a wider ecosystem that will add flexibility to your agents.

The key to this approach is how WebAssembly components interact with the Wasmtime framework, using WebAssembly Interface Types. This exposes typed functions and interfaces, giving you limited and controlled access to the component. If a component requires a string, it will only accept a string. You can also have multiple components written in different languages, all compiled to Wasm and running in the same Wassette host.

You don’t need to learn anything new to build a component interface. They are implemented using the standard interface model in the language you choose before compiling to Wasm and storing in an OCI registry. Interfaces can support multiple operations, and the ByteCode Alliance provides tools to help build components in its GitHub repository.

It’s not hard to write WebAssembly components, and once you start taking advantage of WASI, you can build in local file system and network features, which can be controlled using the Wasmtime permissions framework through Wassette. If you need to add a feature to an agent to provide deeper grounding in actual data, this is one of the most efficient and straightforward ways to expose it via MCP securely.

What’s next for Wassette?

This is an initial release and features are obviously missing. Perhaps the most important is the lack of a discovery feature, both for OCI registries and the WebAssembly components stored in them. For now, if you need a specific component, you need the right OCI URI. As Wassette is an open source project, you can get involved in its development on GitHub.

With Wassette initially targeting developer-focused agents, there’s no real reason it can’t be part of any agent platform that uses MCP. You could use it on a customer service platform, with components that extend your CRM platform into other applications or anywhere that needs functionality that isn’t provided by the core MCP servers you’re using. It’s especially useful when those required functions are small and don’t require much code but still need to be secure with tightly controlled access to resources.

It’s interesting to see a tool like this early in the life of modern AI agents. The combination of discoverable modular code that runs in your local context, along with the ability to quickly add new extensions, reminds me of the work that went into developing agent frameworks like Kaleida back in the 1990s. Today, we can build them on a platform with a local sandbox and we don’t need to learn a whole new language. With Wassette we can develop and deploy the features we need to see in an MCP server, installing them only when needed.