Wassette: running WebAssembly Components as MCP tools with Wasmtime isolation

The problem Wassette solves: tool code you did not write

An MCP agent is only as useful as the tools it can call, and every tool you add is code you are choosing to trust. Wassette's pitch is that the tool runs inside a WebAssembly sandbox instead of inside your agent's process. The README frames this as three properties: convenience (extend an agent without leaving the chat window), reusability (Wasm Components are generic and contain nothing MCP-specific), and security (the Wasmtime sandbox, which the README calls browser-grade isolation).

The audience is narrower than "anyone using AI agents". It is people who already have an MCP client wired up and who care where the tool's code executes. If you are comfortable installing an npm package for every capability your agent needs, Wassette adds a layer you will not value. If you are not, the component model gives you a distributable unit with an explicit interface and a runtime that enforces it.

How the runtime, the registry and the MCP server fit together

The architecture diagram in the repository shows three parties: MCP clients, Wassette, and Wasm Components. The workspace layout matches that split. crates/ holds the runtime, the MCP server and a policy crate; component-registry.json sits at the repository root; examples/ contains one directory per sample component, including arxiv-rs, brave-search-rs, fetch-rs, filesystem-rs, github-js, memory-js and time-server-js.

The dependency list tells you the mechanism. wasmtime, wasmtime-wasi, wasmtime-wasi-http and wasmtime-wasi-config are all pinned at 47.0.4, so components get WASI interfaces rather than raw host access. oci-client 0.17 and oci-wasm 0.6 handle pulling components from OCI registries. rmcp 3.1.3 and mcp-sdk 0.0.3 handle the agent-facing side. A separate policy crate exists, which is where the permission decisions live.

So the data flow is: the agent asks Wassette to load a component by OCI reference, Wassette fetches it, the policy layer decides what that component may do, and the component's exported functions become callable tools over MCP. The README's own example is a time component at oci://ghcr.io/microsoft/time-server-js:latest, which the agent loads and then calls to answer a question about the current time.

Installing Wassette and loading your first component

The README gives a one-line install for Linux and macOS. It pipes a script from the main branch of the GitHub repository into bash, which means you are executing whatever that branch contains at the moment you run it.

curl -fsSL https://raw.githubusercontent.com/microsoft/wassette/main/scripts/install.sh | bash

The README points Windows, Homebrew, Nix and Docker users to the installation guide on the documentation site rather than repeating the steps, so treat the one-liner as the Linux/macOS path only.

Installation is not the interesting part. Registration is. The README says the next step is to register Wassette with your agent, and links a Quick Start guide plus an MCP Clients guide covering GitHub Copilot, Copilot CLI, Claude Code and Codex CLI. That registration step is where the runtime becomes visible to the agent, and the README does not reproduce the config in the repository itself.

Once registered, the interaction is conversational rather than command-line. The README's example prompt is:

Please load the time component from oci://ghcr.io/microsoft/time-server-js:latest

After that load succeeds, a follow-up question about the current time is answered by the component. The README shows the response as a timestamp in UTC. Note the tag in that reference: :latest. For a first run that is fine, but the README does not discuss pinning, and a component that changes under a moving tag is a supply chain question you will have to answer yourself.

What the permissions model implies, and where it is thin

The repository topics list capabilities, permissions, wasm-component and oci-artifacts alongside mcp-server, and there is a dedicated crates/policy. That is the security story in structural terms: a component declares what it needs, and the policy layer decides whether it gets it. wasmtime-wasi-config at the same version as the rest of the Wasmtime crates suggests configuration is passed through a WASI interface rather than read from the host filesystem directly.

The README does not document the policy file format, the default grant set, or what happens when a component requests a capability that policy denies. The phrase "browser-grade isolation" is doing a lot of work in one sentence, and the documentation site is where you would have to go to find the actual rules. Until you have read that, do not assume a loaded component is harmless. A filesystem-rs example exists in the repository, which means some components are intended to touch files, and the interesting question is always which files.

This is the honest limitation: the sandbox is the product, and the repository README does not explain the sandbox's configuration surface. The design intent is clear from the crate layout. The operational detail is not in the README.

Early development is a stated constraint, not a disclaimer

The README carries a warning block in its own words: the repository is not production ready, it is in early development, and it may change significantly. That is unusual to see stated this plainly, and it should govern how you evaluate everything else on this page.

The release history is consistent with that. The releases listed are v0.7.0 from 2026-08-29 and two rolling builds tagged latest-20260830-2013-e1a0f20 and latest-20260829-0113-e12ce57, dated 2026-08-30 and 2026-08-29. The workspace version in Cargo.toml is 0.7.1, ahead of the newest numbered release. Rolling latest-* tags alongside versioned ones usually means the project ships continuously and expects consumers to track a moving target.

The last push was on 2026-09-09, so the codebase is being worked on. That does not contradict the early-development warning. A project can be pushed to daily and still be unsuitable for production, and the maintainers are telling you which one this is. Plan for breaking changes between minor versions, and read RELEASE.md before you build anything that depends on a specific behaviour.

Wassette compared with running MCP tools as native processes

The default way to give an MCP agent a tool is to run a server process on the host, usually a Node or Python package, and let it inherit your user's permissions. That model is simple and it is why so many MCP servers exist. Its failure mode is equally simple: the tool can do anything you can do, and the only boundary is how much you trust the package author.

Wassette replaces that boundary with the component model. The tool is compiled to a WebAssembly Component, pulled as an OCI artifact, and executed by Wasmtime with WASI interfaces and a policy layer in between. The difference is not speed or convenience. It is that the tool's capability set is declared and mediated rather than inherited from your shell.

The cost is real. You need components, not npm packages, so the ecosystem you can draw from is the set of things someone has compiled to a component and published to a registry. The examples directory shows the project building its own: arxiv-rs, brave-search-rs, context7-rs, fetch-rs, github-js, get-weather-js, get-open-meteo-weather-js, gomodule-go, memory-js, eval-py and others. That is a healthy sample of languages, but it is a sample, not a catalogue. If the tool you need exists only as a Python package, Wassette does not help you today.

Licence, maintenance and what an upgrade costs you

Wassette is MIT licensed. The workspace Cargo.toml sets license = "MIT" and license-file = "LICENSE", and the README states the same. MIT is permissive: you can use it commercially, modify it and redistribute it, provided you keep the copyright and licence notice. The repository also carries a NOTICE file and a trademark section stating that use of Microsoft trademarks in modified versions must not imply Microsoft sponsorship. That is a branding condition, not a restriction on the code. Nothing here is legal advice, and if you are redistributing a modified Wassette inside a product, read LICENSE and NOTICE yourself.

The maintenance picture is a project moving quickly under a permissive licence with a self-declared early-development status. Upgrades are the cost. The workspace pins Wasmtime at 47.0.4 across four crates, rmcp at 3.1.3, and oci-wasm at 0.6 with a specific feature set (default-features = false, features = ["rustls-tls"]). Wasmtime major versions move fast and occasionally change WASI behaviour, so a bump from 47 to 48 is the kind of change that can break a component that was working. The release profile in Cargo.toml sets lto = true and codegen-units = 1, which means release builds are slow. Budget for that if you compile from source rather than using a prebuilt binary.

Editorial conclusion

Adopt Wassette if you already run an MCP-capable agent and want third-party tool code confined by Wasmtime rather than by npm or pip trust, and if you can tolerate a project whose own README declares it not production ready. Do not adopt it for production tool execution, for Windows-only workflows that need the one-liner script, or for any component that needs host access the policy layer does not grant. Verify first that your MCP client appears in the mcp-clients guide, that the component you want exists at a pinned OCI tag rather than :latest, and that the permissions your component requests are ones you are willing to grant.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/wassette on GitHub
3. Project website
4. README
5. Releases